3 ms·

I've always thought the problem is that C today doesn't target 8-bits well? The optimizations that most sources mention mostly did not exist in the first versio

I've always thought the problem is that C today doesn't target 8-bits well? The optimizations that most sources mention mostly did not exist in the first version of C

jacquesm 3y ago
No, C on 8 bits was terrible. You could get it to work but the compilers were slow and the code was bloated compared to assembly.
- kjs3 3y ago
  And many/most of them were subsets of the C you'd get on, say, a PDP-11, at the time (although I understand they got better over time). That was what always put me off using C on the 8-bitters. Turbo Pascal on the other hand.......
- shrimp_emoji 3y ago
  Even in the '90s, Diablo was a mix of C and assembly for the bits that C was too slow for! I've heard it said that, if they had the C compilers of today back then, the C code might've been good enough -- hardware being constant -- for them to have totally ditched the assembly, but I don't know how true that is.
  - jacquesm 3y ago
    Yes, but those C compilers of today run on the hardware of today! You wouldn't have been able to compile those C compilers to the point of efficiency required to build them in the first place. Lots of technology is like that. In order to do VLSI you need to do LSI, in order to do LSI you need MSI and so on all the way back to thin film circuits and then individual components. You can't normally skip such steps it's all incremental improvement on what's already there. In software it isn't much different and that software rode in lock-step with the hardware. The best I could do on a relatively fast micro of the 80's in terms of control, expression and eventually execution speed was a very nice macro assembler and given the speed of the storage devices and the raw clock speed of the CPU that was an accomplishment in itself. It pretty much maxed out the hardware. In spite of using clever stuff (hash tables for symbol lookups for instance, which ate up some of that precious memory, RAM disks etc) it still gook a good bit of time to assemble a 16K ROM image. But then I got an Atari ST with a whopping 1M of RAM, a 10 MB hard drive and Mark Williams excellent C compiler and it was off to the races. That was a real game changer for me.
retrac 3y ago
No, it's most high level languages, in general. Pascal or Standard ML for that matter, would suffer just as C does. Languages like C and Pascal really demand that you have a nice, cheap stack. Classically, a function call means pushing all the parameters to the stack, and then the return address, and then jumping to the function, then pulling all the parameters off the stack, and pushing the return value on the stack, then modifying the stack pointer to drop the parameters, and then reading the return address off the stack. Neither the Z80 or 6502, have instructions that provide an efficient stack, which works with multi-byte data. You end up constantly manipulating the stack pointer (usually for a software-implemented stack) with slow 8-bits-at-a-time arithmetic. Painful. The PDP-11's instruction set in comparison, provides not just one, but up to seven, flexible 16-bit stacks.
- ikari_pl 3y ago
  That's some great insight! Mind if I quote it in the post itself?
  - retrac 3y ago
    Thanks, and sure, quote away.
shzhdbi09gv8ioi 3y ago
The classic C compilers were known for producing horribly unoptimized code. It took many years of compiler progress to change C into the performant language we all know and love/hate today.

I've always thought the problem is that C today doesn't target 8-bits well? The optimizations that most sources mention mostly did not exist in the first version of C

jacquesm 3y ago

No, C on 8 bits was terrible. You could get it to work but the compilers were slow and the code was bloated compared to assembly.

kjs3 3y ago
And many/most of them were subsets of the C you'd get on, say, a PDP-11, at the time (although I understand they got better over time). That was what always put me off using C on the 8-bitters. Turbo Pascal on the other hand.......
shrimp_emoji 3y ago
Even in the '90s, Diablo was a mix of C and assembly for the bits that C was too slow for! I've heard it said that, if they had the C compilers of today back then, the C code might've been good enough -- hardware being constant -- for them to have totally ditched the assembly, but I don't know how true that is.
- jacquesm 3y ago
  Yes, but those C compilers of today run on the hardware of today! You wouldn't have been able to compile those C compilers to the point of efficiency required to build them in the first place. Lots of technology is like that. In order to do VLSI you need to do LSI, in order to do LSI you need MSI and so on all the way back to thin film circuits and then individual components. You can't normally skip such steps it's all incremental improvement on what's already there. In software it isn't much different and that software rode in lock-step with the hardware. The best I could do on a relatively fast micro of the 80's in terms of control, expression and eventually execution speed was a very nice macro assembler and given the speed of the storage devices and the raw clock speed of the CPU that was an accomplishment in itself. It pretty much maxed out the hardware. In spite of using clever stuff (hash tables for symbol lookups for instance, which ate up some of that precious memory, RAM disks etc) it still gook a good bit of time to assemble a 16K ROM image. But then I got an Atari ST with a whopping 1M of RAM, a 10 MB hard drive and Mark Williams excellent C compiler and it was off to the races. That was a real game changer for me.

retrac 3y ago

No, it's most high level languages, in general. Pascal or Standard ML for that matter, would suffer just as C does. Languages like C and Pascal really demand that you have a nice, cheap stack. Classically, a function call means pushing all the parameters to the stack, and then the return address, and then jumping to the function, then pulling all the parameters off the stack, and pushing the return value on the stack, then modifying the stack pointer to drop the parameters, and then reading the return address off the stack. Neither the Z80 or 6502, have instructions that provide an efficient stack, which works with multi-byte data. You end up constantly manipulating the stack pointer (usually for a software-implemented stack) with slow 8-bits-at-a-time arithmetic. Painful. The PDP-11's instruction set in comparison, provides not just one, but up to seven, flexible 16-bit stacks.

ikari_pl 3y ago
That's some great insight! Mind if I quote it in the post itself?
- retrac 3y ago
  Thanks, and sure, quote away.

shzhdbi09gv8ioi 3y ago

The classic C compilers were known for producing horribly unoptimized code. It took many years of compiler progress to change C into the performant language we all know and love/hate today.