4 ms·
So going back to Forth is probably not a good idea, but consider this.... 1. Modern CPU microarchitectures issue multiple instructions/micro-instructions per c
by dbcurtis 10y ago
So going back to Forth is probably not a good idea, but consider this....
1. Modern CPU microarchitectures issue multiple instructions/micro-instructions per clock.
2. Modern CPU microarchitectures rely heavily on register renaming in order to avoid bottlenecking on register allocation.
3. High code density is a huge win because: a) highly dense code reduces the cache footprint for a given amount of expressed functionality, which in turn reduces the amount of die area that need be dedicated to instruction cache in a well-balanced processor. b) highly dense code reduces the amount of bus traffic filling the instruction cache from main memory, thus reducing the overall memory bandwidth required to execute a given amount of functionality. Taking a & b together, they explain, in part, why X86 is still king of the hill, and it certainly explains why X86 won over Itanium. X86 code, for all its accumulated cruft, is very dense.
4. Stack machine code is also very dense, because exactly zero bits are dedicated to register names in every instruction.
So... given that the register numbers in typical 2-address or 3-address machines are getting renamed away anyway, why have them at all? Let the compiler generate 0-address code for a stack machine, and let the instruction decoder parse a long string of tokens during a single clock, using standard register renaming techniques to assign virtual stack locations from a large buffer pool. It could issue multiple stack ops per clock, but unwound into simple 3-address micro-ops for the CPU back end. It's really just the final step in moving the register allocator from the compiler to the CPU.
These are all solved problems for the X86 instruction set. Given that existence proof, it is difficult to argue that it would be hard to do for a clean stack-machine ISA.
- microcolonel 10y agoThis is the premise of the Mill architecture; though I haven't heard from them for a while now.
- dbcurtis 10y agoReally? The stuff I've seen about Mill is that they are doing a VLIW machine, which is a very different concept.
- lmitchell 10y agoWhile I think that's true, it's also orthogonal to the 'belt' concept [1] they're using, which I think GP was referring to. I'm also curious about the state of the Mill - judging by the forums on their website they've been basically dark for about a year and a half now, though Ivan Godard claims that everything is still moving along, just slightly slower than expected. [1] https://millcomputing.com/docs/belt/ https://millcomputing.com/docs/belt/
- pkaye 10y agoI don't know why the mill architecture has not gone into production yet. That technology has been in development for 13 years. It brings forth some interesting ideas. What is holding them back?
- honkhonkpants 10y agoIsn't is a volunteer effort?
- pkaye 10y agoIt is a startup though the degree of funding is not clear.
- vertex-four 10y agoLast I heard (about a year ago), the degree of funding wasn't even enough to employ everyone working on it full-time - apparently it was essentially a hobby project for a long time. It might still be. https://www.reddit.com/r/programming/comments/3cn8cz/the_mill_cpu_architecture_the_compiler/csxbbov?context=2 https://www.reddit.com/r/programming/comments/3cn8cz/the_mil...
- agumonkey 10y agoIIUC Henry Baker had a lisp with rust like linear logic encoded in stack machine ISA. http://home.pipeline.com/~hbaker1/ForthStack.html http://home.pipeline.com/~hbaker1/ForthStack.html
- awful 10y agoHaven't followed CPU arch in a very long time so my memory may fail, but the B7700 (1977) based on B5000 (1961) architecture demonstrated what you say on an industrial scale. The machine read in a long 48 bit string of opcodes, mapping them directly to hardware (adders, barrel shifters, inc/dec logic, branch prediction), maximizing throughput by anticipating needs for the next few clocks like setting up and (where possible) execute in different parts of the CPU. Since many operations were already present in pipeline and a cache miss or instruction branch could maybe predicted sooner you could see a long way into the future in some cases. This would leave the memory bus more free for data. And if I remember correctly, it would issue multiple (abstract?) cached stack operations to memory if possible, as the interface was quite sophisticated. And other CPUs could service the stack, SMP, if necessary. I had to troubleshoot these opcodes to the bit level back then, in 1981.
- nigwil_ 10y agoDid you keep any material about your time with the B7700? photos, printer listings, tapes, manuals? We're trying to build an emulator for the Burroughs B6700 (and by extension the B7700) so every scrap of information helps.
- i336_ 10y agoVery interesting! (I say this as someone interested in emulation in general, I sadly am not familiar with Burroughs equipment, although I know the name is synonymous with early cutting edge design.) Does this project have any sort of publicly accessible online home yet?
- nigwil_ 10y agonothing yet, we need to find a complete release of MCP for the Burroughs B6700 before we plan out the project.
- i336_ 10y agoI see, I just took a quick look around the Googles. I'm (somewhat) nearby over the water in Sydney :P I have no idea where I'll end up in the future, but if I ever see anything interesting I now know where to send it.
- abecedarius 10y agoThere was a design for a high-ILP stack processor in the 90s: https://bernd-paysan.de/4stack.html https://bernd-paysan.de/4stack.html but VLIW instead of superscalar.
- deleted 10y ago[deleted]
- __s 10y agoRISC-V papers found x86 to not be very dense. Average instruction is 4 bytes, intruction count is very low. 2 operand instructions are a little less flexible than 3