3 ms·

I kind of enjoy seeing these posts from time to time on HN. I thought it was my age (I remember this hardware) but I think a lot of engineers are enjoying pract

I kind of enjoy seeing these posts from time to time on HN. I thought it was my age (I remember this hardware) but I think a lot of engineers are enjoying practicing their craft in a more pure environment with so few (or no) layers of abstraction underneath. Refreshing at times, isn't it?

dylan604 1y ago
For me, it's less the abstraction vs having hard limits on things like memory. Modern software has nearly limitless memory compared to the less than 1MB typical on these projects. It was definitely a lesson I had to learn. As far as the abstraction, when does it get to a point the compiler can't undo the abstraction? At what point does one need to get to a point where something cannot be done?
- tmoertel 1y ago
  On 6502-based systems the available memory was often less than 64 KiB, the maximum addressable by the processor directly. Still, you could squeeze a lot into that small amount of you were clever. For example, Steve Wozniak wrote in BYTE magazine about computing e to over 100K places on an Apple 2: > I first calculated e to 47 K bytes of precision in January 1978. The program ran for 4.5 days, and the binary result was saved on cassette tape. Because I had no way of detecting lost-bit errors on the Apple (16 K-byte dynamic memory circuits were new items back then), a second result, matching the first, was required. Only then would I have enough confidence in the binary result to print it in decimal. Before I could rerun the 4.5 day program successfully, other projects at Apple, principally the floppy-disk controller, forced me to deposit the project in the bottom drawer. This article, already begun, was postponed along with it. Two years later, in March 1980, I pulled the e project out of the drawer and reran it, obtaining the same results. As usual (for some of us), writing the magazine article consumed more time than that spent meeting the technical challenges. See page 392 of https://archive.org/details/byte-magazine-1981-06 https://archive.org/details/byte-magazine-1981-06.
- HarHarVeryFunny 1y ago
  > As far as the abstraction, when does it get to a point the compiler can't undo the abstraction? The early 8-bit systems were so constrained in everything from memory to registers, instruction set, and clock speed, that using a high level language wasn't an option if you were trying to optimize performance or squeeze a lot of functionality into available memory. An 8-bit system would have a 64KB address space, but maybe only 16-32KB of RAM, with the rest used by the "OS" and mapped to the display, etc. The 6502 was especially impoverished, having only three 8-bit registers and a very minimalistic instruction set. Writing performant software for it depended heavily on using "zero-page" memory (special addressing mode to access 1st 256 bytes of memory) to hold variables, rather than passing stack based parameters to functions, etc. It was really a completely different style of programming and mindset to using a high level language - not about language abstraction, but a painful awareness of the bare metal you were running on all the time.
  - dylan604 1y ago
    When I asked, it was based on my use of Arduino IDE where one writes higher level code that then gets compiled into machine code. I had a project where I was using multiple sensors where I could not store each of their responses in memory to write to a log in one shot. Instead, I had to write to the log after reading each sensor directly and releasing the memory at the end of each loop. I was originally hoping to do more analysis with the data onboard the Arduino, but in hindsight, that was a pretty dumb idea. The sensing platform should do just that. Do the analysis in post.
- asveikau 1y ago
  I may sound bitter in describing this, but I started to notice about 15 years ago that the then-current crop of developers, trained exclusively on GC'd languages, seemed to have no idea what a memory constraint would look like and thought that a hidden memory allocation is free as long as it occurs a few layers beneath you.
  - dylan604 1y ago
    Formal training with something like a CS course definitely starts with limited systems progressing to larger systems. So if you've been through that pain, I could see the bitterness. However, I'd wager the vast majority of coders did not take a CS course, and are self taught or boot camp grads. It's not really their fault they don't know assembly. It's just not something they've ever or will most likely never need to deal with for they day job.
    - inopinatus 1y ago
      The painful thing is when someone describes themselves as a “full stack developer” but lack any mechanical sympathy for what the processor, memory, and I/O buses are actually doing. This doesn’t require a formal education. I was self-taught long before studying CS institutionally. And per the article I am super grateful to the 6502 for being the platform that I learned from.
      - pixl97 1y ago
        I mean, no, that's mostly not what I'd consider a full stack developer myself and I've been around a long time. You can be full stack grabbing everyone else's libraries and making an app spit data from the db to the UI. Simply put the vast majority of developers will never need this information nor be resource constrained that they'll need to use their time to understand the issue deeper.
        deleted 1y ago
        [deleted]
    - 1y ago
deleted 1y ago
[deleted]
matheusmoreira 1y ago
"Low-level programming is good for the programmer’s soul." -- John Carmack

dylan604 1y ago

For me, it's less the abstraction vs having hard limits on things like memory. Modern software has nearly limitless memory compared to the less than 1MB typical on these projects. It was definitely a lesson I had to learn. As far as the abstraction, when does it get to a point the compiler can't undo the abstraction? At what point does one need to get to a point where something cannot be done?

tmoertel 1y ago
On 6502-based systems the available memory was often less than 64 KiB, the maximum addressable by the processor directly. Still, you could squeeze a lot into that small amount of you were clever. For example, Steve Wozniak wrote in BYTE magazine about computing e to over 100K places on an Apple 2: > I first calculated e to 47 K bytes of precision in January 1978. The program ran for 4.5 days, and the binary result was saved on cassette tape. Because I had no way of detecting lost-bit errors on the Apple (16 K-byte dynamic memory circuits were new items back then), a second result, matching the first, was required. Only then would I have enough confidence in the binary result to print it in decimal. Before I could rerun the 4.5 day program successfully, other projects at Apple, principally the floppy-disk controller, forced me to deposit the project in the bottom drawer. This article, already begun, was postponed along with it. Two years later, in March 1980, I pulled the e project out of the drawer and reran it, obtaining the same results. As usual (for some of us), writing the magazine article consumed more time than that spent meeting the technical challenges. See page 392 of https://archive.org/details/byte-magazine-1981-06 https://archive.org/details/byte-magazine-1981-06.
HarHarVeryFunny 1y ago
> As far as the abstraction, when does it get to a point the compiler can't undo the abstraction? The early 8-bit systems were so constrained in everything from memory to registers, instruction set, and clock speed, that using a high level language wasn't an option if you were trying to optimize performance or squeeze a lot of functionality into available memory. An 8-bit system would have a 64KB address space, but maybe only 16-32KB of RAM, with the rest used by the "OS" and mapped to the display, etc. The 6502 was especially impoverished, having only three 8-bit registers and a very minimalistic instruction set. Writing performant software for it depended heavily on using "zero-page" memory (special addressing mode to access 1st 256 bytes of memory) to hold variables, rather than passing stack based parameters to functions, etc. It was really a completely different style of programming and mindset to using a high level language - not about language abstraction, but a painful awareness of the bare metal you were running on all the time.
- dylan604 1y ago
  When I asked, it was based on my use of Arduino IDE where one writes higher level code that then gets compiled into machine code. I had a project where I was using multiple sensors where I could not store each of their responses in memory to write to a log in one shot. Instead, I had to write to the log after reading each sensor directly and releasing the memory at the end of each loop. I was originally hoping to do more analysis with the data onboard the Arduino, but in hindsight, that was a pretty dumb idea. The sensing platform should do just that. Do the analysis in post.
asveikau 1y ago
I may sound bitter in describing this, but I started to notice about 15 years ago that the then-current crop of developers, trained exclusively on GC'd languages, seemed to have no idea what a memory constraint would look like and thought that a hidden memory allocation is free as long as it occurs a few layers beneath you.
- dylan604 1y ago
  Formal training with something like a CS course definitely starts with limited systems progressing to larger systems. So if you've been through that pain, I could see the bitterness. However, I'd wager the vast majority of coders did not take a CS course, and are self taught or boot camp grads. It's not really their fault they don't know assembly. It's just not something they've ever or will most likely never need to deal with for they day job.
  - inopinatus 1y ago
    The painful thing is when someone describes themselves as a “full stack developer” but lack any mechanical sympathy for what the processor, memory, and I/O buses are actually doing. This doesn’t require a formal education. I was self-taught long before studying CS institutionally. And per the article I am super grateful to the 6502 for being the platform that I learned from.
    - pixl97 1y ago
      I mean, no, that's mostly not what I'd consider a full stack developer myself and I've been around a long time. You can be full stack grabbing everyone else's libraries and making an app spit data from the db to the UI. Simply put the vast majority of developers will never need this information nor be resource constrained that they'll need to use their time to understand the issue deeper.
      - deleted 1y ago
        [deleted]
  - 1y ago

deleted 1y ago

[deleted]

matheusmoreira 1y ago

"Low-level programming is good for the programmer’s soul." -- John Carmack