3 ms·

I am reading the comments, and am open to critique or general suggestions. “I found this part confusing” is also very welcome. This is quite an information den

I am reading the comments, and am open to critique or general suggestions. “I found this part confusing” is also very welcome. This is quite an information dense work, and a little rough around the edges, though I am pretty happy with it overall.

cnasc 7y ago
I'm only a little way through it so far, so I'll come back with any questions, but I'd like to thank you for sharing such an interesting read!
h2odragon 7y ago
I almost understand some of these words :) Truly this is fascinating and makes me want to learn about the many things i do not grasp yet. Thank you. > Register hazards are an unavoidable consequence from using a limited number of names to refer to an unbounded to number of source-level values yet I seem to recall seeing compiler writers lament the paucity of registers too. Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something. gimme instruction level access to all of what is now cache. (chuck all the cache handler logic btw). let me page in and out sections of that to main memory or the inter cpu or io busses, but otherwise its all storage and the real difference is latency. if we want to burn hardware there could be special graded coherency memory areas or transactional or content addressable.
- deepnotderp 7y ago
  > Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something Please no, however hard you think register renaming is, memory disambiguation is harder.
  - h2odragon 7y ago
    Hey I'll argue for self modifying code if you let me :). Don't let it be ambiguous. I may be trying to express "don't add abstractions" let the hardware limits show, in ignorance of what the hardware limits are.
ajb 7y ago
You might also be interested in Sophie Wilson's "Generation renaming" scheme. Unfortunately AFAIK the only open description of it is in the patents, which of course are written in patentese: https://patentimages.storage.googleapis.com/e2/c4/39/301ea43095e5c9/EP2937775A1.pdf https://patentimages.storage.googleapis.com/e2/c4/39/301ea43... https://patentimages.storage.googleapis.com/fd/de/de/7fdbc306db9068/EP2937776A3.pdf https://patentimages.storage.googleapis.com/fd/de/de/7fdbc30...
bullen 7y ago
I'm also a little bit behind on the semantics and understanding. From my perspective we need to make the CPU more user friendly first, so I would like a VM (without GC) in silicon. Basically removing the absurdities of the memory and error handling that we get now. I still have no clue if this is possible? Then I think going back to 8-bits and making a purely parallel multi-core processor with segregated transistor memory and shared DRAM would be an interesting idea, just to see how that would work out with today's lithography and memory bottlenecks. Of course you would have to code differently so the programming language would have to change by adding local and remote memory to the variables and explicitly handling concurrency without blocking to the remote memory somehow. Possibly by copying, which is slow, but that memory is already going to be slow. The common path for both of these is lets make things complex in a different ways separately to see if we can make life for programmers better, one by removing frustration and worry the other by keeping the energy efficient scaling and memory speeds going for a tad more.

cnasc 7y ago

I'm only a little way through it so far, so I'll come back with any questions, but I'd like to thank you for sharing such an interesting read!

h2odragon 7y ago

I almost understand some of these words :) Truly this is fascinating and makes me want to learn about the many things i do not grasp yet. Thank you. > Register hazards are an unavoidable consequence from using a limited number of names to refer to an unbounded to number of source-level values yet I seem to recall seeing compiler writers lament the paucity of registers too. Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something. gimme instruction level access to all of what is now cache. (chuck all the cache handler logic btw). let me page in and out sections of that to main memory or the inter cpu or io busses, but otherwise its all storage and the real difference is latency. if we want to burn hardware there could be special graded coherency memory areas or transactional or content addressable.

deepnotderp 7y ago
> Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something Please no, however hard you think register renaming is, memory disambiguation is harder.
- h2odragon 7y ago
  Hey I'll argue for self modifying code if you let me :). Don't let it be ambiguous. I may be trying to express "don't add abstractions" let the hardware limits show, in ignorance of what the hardware limits are.

ajb 7y ago

You might also be interested in Sophie Wilson's "Generation renaming" scheme. Unfortunately AFAIK the only open description of it is in the patents, which of course are written in patentese: https://patentimages.storage.googleapis.com/e2/c4/39/301ea43095e5c9/EP2937775A1.pdf https://patentimages.storage.googleapis.com/e2/c4/39/301ea43... https://patentimages.storage.googleapis.com/fd/de/de/7fdbc306db9068/EP2937776A3.pdf https://patentimages.storage.googleapis.com/fd/de/de/7fdbc30...

bullen 7y ago

I'm also a little bit behind on the semantics and understanding. From my perspective we need to make the CPU more user friendly first, so I would like a VM (without GC) in silicon. Basically removing the absurdities of the memory and error handling that we get now. I still have no clue if this is possible? Then I think going back to 8-bits and making a purely parallel multi-core processor with segregated transistor memory and shared DRAM would be an interesting idea, just to see how that would work out with today's lithography and memory bottlenecks. Of course you would have to code differently so the programming language would have to change by adding local and remote memory to the variables and explicitly handling concurrency without blocking to the remote memory somehow. Possibly by copying, which is slow, but that memory is already going to be slow. The common path for both of these is lets make things complex in a different ways separately to see if we can make life for programmers better, one by removing frustration and worry the other by keeping the energy efficient scaling and memory speeds going for a tad more.