41–50 of 387 posts
In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware).
Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM).
Some java subsets for very limited hardware might be instances.
Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?
That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be because it was already people writing in C were aware of.
-- Micha Niskin
C has never been "how the computer works", its abstract model is way too… well, abstract. But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them. A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a mai…
"Concurrent access" isn't actually an accurate description of what's going on. Microcontrollers are generally single-core, single-threaded devices. The most common pipeline goes main thread -> interrupt processing -> resume main thread. If you're modifying a variable in the interrupt you should declare it volatile so as to avoid the compiler optimizing it and introducing unexpected behavior. Adding a mutex would just…
Of course, it didn't do that. Because vendors imparted their compilers with additional knowledge about common programming patterns and uses that aren't standard C.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
It would also be nice if Rust had a specification. Without a spec it's impossible to build a correct alternative Rust implementation.
Earlier quoted context omitted.
Steve Klabnik, of Rust fame, has a good history of writing insightful and interesting articles. If you feel he isn't delivering value then feel free to output your own content instead of contributing to drive down the signal/noise ratio of HN's comments section with inane comments on other people's tastes.
Thank _you_ for raising it! My comment was about the linked post. Yours wasn't. Whose doing what?
This has required a fair bit of assembly language for old machines with a much more minimal profit motive - in fact, non-existent - just so that I can keep my machines alive - which is the reason I'm digging into things as a bit of a challenge to myself.
There is so much great code to read, when you can disassemble. And, even when you can't.
I have a veritable fleet of old systems, many of which are still getting new titles released at astonishing levels of proficiency, yearly now .. CPC6128, ZX (Next!), C64, Atmos, BBC, etc., all have new tools being written for them, including C compilers.
One thing I note is that the tools are everything, because all tools get 'degraded' by new hardware releases. Hardware isn't driven by the compiler designer - the compiler designer is nothing until the hardware guy prints something.
Returning to older computers has meant understanding their architecture, and surprisingly enough after 30 years of mainstream programming, going back to this world is rewarding. There is a lot of joy in writing in C for the 6502, or even Z80, in real mode.
But, always disassemble.
And, in each case, its quite easy to disassemble - get an understanding of registers and memory usage and code inefficiencies, and so on.
Is the world ready for lower-level languages ? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware). Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM). Some java subsets for very limited hardware might be instances.
Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?