2021 ...

januari februari (3) maart (2) april mei (25) juni (23) juli (21) augustus (29) september (18) oktober (21) november (29) december (30)

Quick, write it down: just another CPU design idea

2021-05-05 23:57  cpuidea     [permalink]

Ever since learning about the Mill architecture, and watching an excellent series of MIT 6.004 lectures by Chris Terman (I can't find them on Youtube any more! But there are newer versions of 6.004 online which probably are great as well.) and reading up on what's new about x64 and RISC-V and ARM, from time to time my mind wanders if you could go crazy and design yet another CPU design that does novel things with the umptillions of available transistors and not have the downsides of the currently popular CPU's.

So here's an idea I just need to write out of my system, and let you have a look so you can see if there's anything there at all. Modern CPU's use virtual registers to have hyperthreading and speculative execution, and push whatever ahead in the hope it was the right branch to make pipelining work better for the workload at hand. The Mill architecture would handle that a little different and fill the pipeline just with more concurrent threads and interleave those. (At least that's how I understood what would be going on.)

What if you design a CPU so that it also takes in a larger set of streams of instructions, also using a bank of virtual registers that get alotted to these streams, but also have hot memory just like the closest cache is, but use that for the stack. Ideally you could expect programs to keep the current stack-frame fit within one or a few kilobytes, and by having a larger number of streams you could avoid having to switch this stack along with all the rest on context changes (by the OS). Switching the stack and overflowing the stack to and from memory is something that will have to happen, so you'll have decent support for that, but if you're after speed you'll try to avoid it as much as possible.

Let's have some numbers just to get a clearer mental picture. Let's say a core has support for 256 streams of instructions. If the work for them is pipe-lines across the rest of the core, addressing them would take 8 bits, so you would see a band of 8 lines pipe-lined to everything everywhere. It's not even required to have 256 instruction decoders, and sub-groups of streams could share commen instruction decoders, but depending on the instruction set design itself, this could turn out to be the bottleneck, but let's find that out with further design and research.

Let's say each stream gets 4KiB of hot stack memory, in total is 1MiB which is not unrealistic to have in a modern code nowadays, if I understood that correctly. This special memory could have extra lines so it automatically flows over into system's memory if the local stack index rolls over, which perhaps could also help with loading and flushing stack data on context changes.

With instruction fetching, stack handling and these streams doing their thing with alotted virtual registers, there's a lot covered, but the ofcourse the sweet magic happens in ALU's and related things, so down the pipe-line, according to what instruction decoding prescribes, the streams queue up to get one of the available ALU's to handle an operation.

This would be a point at which you start on a real design in a simulator, but that's where my knowledge is stronger than my experience. I just decide to start writing things down (right here, right now), let it simmer a bit and maybe pickup starting a first attempt sometime later. If you see what a former attempt like plasm ("play assembler") looks, don't get your hopes up too much. For now it's good that I wrote the core idea down here. If I ever get down to it again and get something working, you'll read it here. Sometime later.

→

"Wat zijn die witte vlakken?"

2021-05-11 12:00  pre-fxy      [permalink]

Als je dit leest, ben je mogelijk het archief van deze website aan het uitpluizen. Dan kan je vanaf deze post 'andere' posts zien met een witte achtergrond. Deze komen van een 'express' functie op mijn RSS feed reader 'feeder'. Deze bestond al langer voor ik de koppeling kon maken om wat ik daar optekende ook om te zetten in blog-posts hier. Meer uitleg vind je hier: http://yoy.be/feederexpressyoy.html

→

Feeder + eater... + opinions?

2021-05-12 22:16  feederopinions       [permalink]

→ https://github.com/stijnsanders/feeder/commit/a34f311394b842ef5dca716be32c31ca979fdb1a

What an idea. Imagine a place where you can vent impressions of the moment, except you have to do so in response to a title and URL that has to have come in over an RSS feed you're subscribed to on beforehand. Could that be something? Or would the ideal public in this specific niche be much to narrow? (It's probably at least one, since it looks like it would at least serve me.)

→

Maybe 'invisibility' will kill RSS

2021-05-19 07:32  invisiblerss      [permalink]

How can we make RSS 'more visible'? Among the news-sites I've added the RSS feed to my RSS reader, I see a common thing happen a few times now: They build a new website that looks better, and — bam — the feed URL responds with a 404, or worse a 500, HTTP response. I guess what happens is that by selecting a new platform, the main core feature(s) is provided — listing new articles — in a new design that looks better, and these designers don't know about the feed because they can't see it. Perhaps in most cases it doesn't even show in the page view statistics...

In a better world, they would soon notice a viewership drop especially by the people that would previously follow a link from a feed, but I know full well that us feed-readers are a minority group that's easily left out of the numbers, and that news feeds themselves are a sensitive subject because we're using their content and can't directly generate income.

The least I can do is send an e-mail to a support address if I can find one, notifying I'm getting less service than before. I don't expect them to really do anything about it. Or even respond. I guess we shoud get the message and accept we're not wanted in their slice of the public. Some do restore the feed, or build a feed on the new platform, though. So even I don't get a response, from time to time I check to see if they still love us. (Or if there's a way to get what we want directly from the new platform...)

→