8 ms·

> The compiler is 324k in size Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.

by hgs3 3y ago

bigbillheck 3y ago
The clang executable on my machine is 18kb.
- AnimalMuppet 3y ago
  I bet it forks some other executables, though...
- catiopatio 3y ago
  On my system, where clang is statically linked, the binary is 48mb. As in megabytes. Nearly all of clang and LLVM are linked as libraries.
retrac 3y ago
Your optimizing compiler today will actually optimize. LLVM was recently ported to the 6502 (yes, really) [1]. An example: void outchar (char c) { c = c | 0x80; asm volatile ("jsr $fbfd\n" : : "a" (c): "a"); } void outstr (char* str) { while (*str != 0) outchar(*str++); } void main () { outstr("Hello, world!\n"); } That is compiled to this: lda #$c8 ; ASCII H | 0x80 jsr $fbfd lda #$e5 ; ASCII e | 0x80 jsr $fbfd ... Unrolled loop, over a function applied to a constant string at compile time. An assembler programmer couldn't do better. It is the fastest way to output that string so long as you rely on the ROM routine at $fbfd. (Apple II, for the curious.) Such an optimizing transform is unremarkable today. But stuff like that was cutting edge in the 90s. [1] https://llvm-mos.org/wiki/Welcome https://llvm-mos.org/wiki/Welcome
- Someone 3y ago
  Does it end that code with a jmp $fbfd ?
  - mananaysiempre 3y ago
    Doubtful, given the JSR comes from an inline asm. You’d need to code the call in C (with an appropriate calling convention, which I don’t know if this port defines) for Clang to be able to optimize a tail-position call into a jump—which it is capable of doing, generally speaking.
  - retrac 3y ago
    No. The compiler knows that trick for its own code :) not sure about introspecting into the assembly (I think LLVM doesn't do that). But either way, standard C returns int of 0 from main on success. So: ldx #0 txa rts
    - Someone 3y ago
      Nitpick: this isn’t standard C (it uses void main, not int main) Nitpick 2: why ldx #0 txa rts? I would think lda #0 rts is shorter and faster Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct. I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value. If that value isn’t used, why spend time setting it? A assembly programmer also would: - check whether the routine at 0xFBFD accidentally guarantees to set A to zero, or returns with the X or Y register set to zero, and shamelessly exploit that. - check whether the code at 0xFBFD preserves the value of the accumulator (unlikely, I would guess, but if it does, the two consecutive ‘l’s need only one LDA#) - consider replacing the code to output the space inside “hello world” by a call to FBF4 (move cursor right). That has the same effect if there already is a space there when the code is called. - call 0xFBF0 to output a printable character, not 0xFBFD (reading https://6502disassembly.com/a2-rom/APPLE2.ROM.html https://6502disassembly.com/a2-rom/APPLE2.ROM.html, I notice that is faster for letters and punctuation) On a 6502, that’s how you get your code fit into memory and make it faster. To write good code for a 6502, you can’t be concerned about calling conventions or having individually testable functions.
      - tom_ 3y ago
        I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0. Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll be content with the string printing taking about as long as it takes, which clearly isn't too long, as they wouldn't have done it that way otherwise. And the loop "overhead" won't be meaningful. (Looks like it'll be something like 7 cycles per character? I'm not familiar with the Apple II. Looks like $fbfd preserves X though.)
- MatthiasPortzel 3y ago
  I understand your point, but LLVM-MOS is a bad example. You gain LLVM’s language optimizations, as you point out. But LLVM’s assumed architecture is so different from the 6502 that lowering the code to assembly introduces many superfluous instructions. (As an example, the 6502 has one general purpose register, but LLVM works best with many registers. So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used.) It’s of course possible to further optimize this, but the LLVM-MOS project isn’t that mature yet. So assembly programmers can still very much do better.
  - chongli 3y ago
    So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used. Isn’t this actually good practice on the 6502? The processor treats the first page of memory (called the zero page) differently. Instructions that address the zero page are shorter because they leave out the most significant byte. Addressing any other page requires that extra byte for the MSB. Furthermore, instructions which accept a zero page address typically complete one cycle faster than absolute addressed instructions, and typically only one cycle slower than immediate addressed instructions. So if you can keep as much of your memory accesses within the zero page as possible, your code will run a lot faster. It would seem to me that treating the zero page as a table of virtual registers is a great way to do that because you can bring all your register colouring machinery to bear on the problem.
  - tredre3 3y ago
    I understand your point but the beginning of the zero page is almost always used as virtual registers by regular hand-rolled 6502 applications. So it's pretty normal for LLVM to do the same, it's not an example of LLVM doing something weird.
- pjmlp 3y ago
  Not really that wonder, other that 6502 sucks for C. "An overview of the PL.8 compiler", circa 1976 https://dl.acm.org/doi/abs/10.1145/989393.989400 https://dl.acm.org/doi/abs/10.1145/989393.989400
- retrocryptid 3y ago
  Well... I mean... if you want inverse video.
Aurornis 3y ago
There’s nothing stopping anyone from going back and using all of that old software exclusively. For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
- TillE 3y ago
  Binary size on a desktop OS is almost totally irrelevant in practice. Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't. People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
  - Max-q 3y ago
    Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive. Bloat making software bigger will in many cases also make it slower. Also, the UX on Windows 95 was consistent and easy to learn. Now, much software fail on stuff like disabling a button when you have clicked it and the computer is working. MacOS is on a steady curve to the bottom. It is not alone. The software bloat and decreasing quality is a serious issue.
    - gizajob 3y ago
      We need Stevesie to reincarnate and fire whoever is Scott-Forestall-ing it up this year.
      - musicale 3y ago
        I still think iOS was more fun in the Forstall-skeuomorphic era, and screen elements were easier to differentiate. macOS icons also used to have distinct silhouettes which made them easier to distinguish, but now everything is a square tile. Screen controls which used to be visible and targetable are now hidden and are harder to hit when they do appear. It feels like we are still under the tyranny of the (Jony Ivian?) streamlined aesthetic over usability and functionality, as if a library decided to organize books by size and color.
deleted 3y ago
[deleted]

> The compiler is 324k in size Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.

by hgs3 3y ago

> The compiler is 324k in size Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.

bigbillheck 3y ago

The clang executable on my machine is 18kb.

AnimalMuppet 3y ago
I bet it forks some other executables, though...
catiopatio 3y ago
On my system, where clang is statically linked, the binary is 48mb. As in megabytes. Nearly all of clang and LLVM are linked as libraries.

retrac 3y ago

Your optimizing compiler today will actually optimize. LLVM was recently ported to the 6502 (yes, really) [1]. An example: void outchar (char c) { c = c | 0x80; asm volatile ("jsr $fbfd\n" : : "a" (c): "a"); } void outstr (char* str) { while (*str != 0) outchar(*str++); } void main () { outstr("Hello, world!\n"); } That is compiled to this: lda #$c8 ; ASCII H | 0x80 jsr $fbfd lda #$e5 ; ASCII e | 0x80 jsr $fbfd ... Unrolled loop, over a function applied to a constant string at compile time. An assembler programmer couldn't do better. It is the fastest way to output that string so long as you rely on the ROM routine at $fbfd. (Apple II, for the curious.) Such an optimizing transform is unremarkable today. But stuff like that was cutting edge in the 90s. [1] https://llvm-mos.org/wiki/Welcome https://llvm-mos.org/wiki/Welcome

Someone 3y ago
Does it end that code with a jmp $fbfd ?
- mananaysiempre 3y ago
  Doubtful, given the JSR comes from an inline asm. You’d need to code the call in C (with an appropriate calling convention, which I don’t know if this port defines) for Clang to be able to optimize a tail-position call into a jump—which it is capable of doing, generally speaking.
- retrac 3y ago
  No. The compiler knows that trick for its own code :) not sure about introspecting into the assembly (I think LLVM doesn't do that). But either way, standard C returns int of 0 from main on success. So: ldx #0 txa rts
  - Someone 3y ago
    Nitpick: this isn’t standard C (it uses void main, not int main) Nitpick 2: why ldx #0 txa rts? I would think lda #0 rts is shorter and faster Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct. I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value. If that value isn’t used, why spend time setting it? A assembly programmer also would: - check whether the routine at 0xFBFD accidentally guarantees to set A to zero, or returns with the X or Y register set to zero, and shamelessly exploit that. - check whether the code at 0xFBFD preserves the value of the accumulator (unlikely, I would guess, but if it does, the two consecutive ‘l’s need only one LDA#) - consider replacing the code to output the space inside “hello world” by a call to FBF4 (move cursor right). That has the same effect if there already is a space there when the code is called. - call 0xFBF0 to output a printable character, not 0xFBFD (reading https://6502disassembly.com/a2-rom/APPLE2.ROM.html https://6502disassembly.com/a2-rom/APPLE2.ROM.html, I notice that is faster for letters and punctuation) On a 6502, that’s how you get your code fit into memory and make it faster. To write good code for a 6502, you can’t be concerned about calling conventions or having individually testable functions.
    - tom_ 3y ago
      I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0. Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll be content with the string printing taking about as long as it takes, which clearly isn't too long, as they wouldn't have done it that way otherwise. And the loop "overhead" won't be meaningful. (Looks like it'll be something like 7 cycles per character? I'm not familiar with the Apple II. Looks like $fbfd preserves X though.)
MatthiasPortzel 3y ago
I understand your point, but LLVM-MOS is a bad example. You gain LLVM’s language optimizations, as you point out. But LLVM’s assumed architecture is so different from the 6502 that lowering the code to assembly introduces many superfluous instructions. (As an example, the 6502 has one general purpose register, but LLVM works best with many registers. So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used.) It’s of course possible to further optimize this, but the LLVM-MOS project isn’t that mature yet. So assembly programmers can still very much do better.
- chongli 3y ago
  So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used. Isn’t this actually good practice on the 6502? The processor treats the first page of memory (called the zero page) differently. Instructions that address the zero page are shorter because they leave out the most significant byte. Addressing any other page requires that extra byte for the MSB. Furthermore, instructions which accept a zero page address typically complete one cycle faster than absolute addressed instructions, and typically only one cycle slower than immediate addressed instructions. So if you can keep as much of your memory accesses within the zero page as possible, your code will run a lot faster. It would seem to me that treating the zero page as a table of virtual registers is a great way to do that because you can bring all your register colouring machinery to bear on the problem.
- tredre3 3y ago
  I understand your point but the beginning of the zero page is almost always used as virtual registers by regular hand-rolled 6502 applications. So it's pretty normal for LLVM to do the same, it's not an example of LLVM doing something weird.
pjmlp 3y ago
Not really that wonder, other that 6502 sucks for C. "An overview of the PL.8 compiler", circa 1976 https://dl.acm.org/doi/abs/10.1145/989393.989400 https://dl.acm.org/doi/abs/10.1145/989393.989400
retrocryptid 3y ago
Well... I mean... if you want inverse video.

Aurornis 3y ago

There’s nothing stopping anyone from going back and using all of that old software exclusively. For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?

TillE 3y ago
Binary size on a desktop OS is almost totally irrelevant in practice. Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't. People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
- Max-q 3y ago
  Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive. Bloat making software bigger will in many cases also make it slower. Also, the UX on Windows 95 was consistent and easy to learn. Now, much software fail on stuff like disabling a button when you have clicked it and the computer is working. MacOS is on a steady curve to the bottom. It is not alone. The software bloat and decreasing quality is a serious issue.
  - gizajob 3y ago
    We need Stevesie to reincarnate and fire whoever is Scott-Forestall-ing it up this year.
    - musicale 3y ago
      I still think iOS was more fun in the Forstall-skeuomorphic era, and screen elements were easier to differentiate. macOS icons also used to have distinct silhouettes which made them easier to distinguish, but now everything is a square tile. Screen controls which used to be visible and targetable are now hidden and are harder to hit when they do appear. It feels like we are still under the tyranny of the (Jony Ivian?) streamlined aesthetic over usability and functionality, as if a library decided to organize books by size and color.

deleted 3y ago

[deleted]