4 ms·

This looks like a fun historical view of programming in the 70s and 80s. The section about C, though, I'm sorry to say is littered with flaws and should be rew

by unwind 3y ago

This looks like a fun historical view of programming in the 70s and 80s. The section about C, though, I'm sorry to say is littered with flaws and should be rewritten and/or proof-read by someone with more knowledge about the language. Not impressed.

guenthert 3y ago
Indeed. I noticed "Going further, as was a common convention in assembly to pass the return value in the A (for 8-bit, later AX for 16-bit, and EAX for 32-bit) register of the processor (because it is faster than by a value in memory),". That is not the reason. While on many architectures, except perhaps 6502, it was faster (before we had first level data caches as fast as registers), the reason was reentrancy. And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz like a Speccie. (sorry, couldn't resist)
- flohofwoe 3y ago
  > And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz... It's quite common to be mistaken though, because the Z80 in the CPC was not running at full 4 MHz speed (even though it's clocked at 4Mhz). The gate array would set the Z80's WAIT pin for 3 out of 4 clock cycles to create a window for the gate array to read pixel data from memory. This causes the Z80 to fall into a 4-cycle-aligned pattern, meaning that memory access machine cycles were stretched from 3 to 4 clock cycles, resulting in an effective speed of somewhere between 3 and 4 MHz (depending on the instruction mix, but probably averaging somewhere around 3.5 Mhz). > ... the reason was reentrancy. ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered.
  - ikari_pl 3y ago
    > ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered. But stack is memory. At least in these systems. So I think the problems could rise if we would throw concurrency into the picture, where you also have to synchronize the memory access, maybe?
    - flohofwoe 3y ago
      Switching to a different "thread" would also switch to a different stack though (although that would be kinda tricky on a 6502 where the stack is hardwired to the $100 page). Actual multithreading on an 8-bit CPU is a bit of an esoteric topic though, usually one only has to deal with interrupt service routines running concurrently :)
    - Jare 3y ago
      You're already using the stack for parameters without compromising reentrancy; using the stack for the return value is trivial. Just like parameters, it's easier and faster to use registers where possible in those old systems.

by unwind 3y ago

guenthert 3y ago

Indeed. I noticed "Going further, as was a common convention in assembly to pass the return value in the A (for 8-bit, later AX for 16-bit, and EAX for 32-bit) register of the processor (because it is faster than by a value in memory),". That is not the reason. While on many architectures, except perhaps 6502, it was faster (before we had first level data caches as fast as registers), the reason was reentrancy. And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz like a Speccie. (sorry, couldn't resist)

flohofwoe 3y ago
> And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz... It's quite common to be mistaken though, because the Z80 in the CPC was not running at full 4 MHz speed (even though it's clocked at 4Mhz). The gate array would set the Z80's WAIT pin for 3 out of 4 clock cycles to create a window for the gate array to read pixel data from memory. This causes the Z80 to fall into a 4-cycle-aligned pattern, meaning that memory access machine cycles were stretched from 3 to 4 clock cycles, resulting in an effective speed of somewhere between 3 and 4 MHz (depending on the instruction mix, but probably averaging somewhere around 3.5 Mhz). > ... the reason was reentrancy. ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered.
- ikari_pl 3y ago
  > ...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered. But stack is memory. At least in these systems. So I think the problems could rise if we would throw concurrency into the picture, where you also have to synchronize the memory access, maybe?
  - flohofwoe 3y ago
    Switching to a different "thread" would also switch to a different stack though (although that would be kinda tricky on a 6502 where the stack is hardwired to the $100 page). Actual multithreading on an 8-bit CPU is a bit of an esoteric topic though, usually one only has to deal with interrupt service routines running concurrently :)
  - Jare 3y ago
    You're already using the stack for parameters without compromising reentrancy; using the stack for the return value is trivial. Just like parameters, it's easier and faster to use registers where possible in those old systems.