4 ms·
If it can be done efficiently in asm then it can be done in C, C++, perhaps even Rust. But there are sacrifices to be made: unmaintainable “clever” code without
by TazeTSchnitzel 7y ago
If it can be done efficiently in asm then it can be done in C, C++, perhaps even Rust. But there are sacrifices to be made: unmaintainable “clever” code without clean abstractions.
- vardump 7y agoThere are architectures that are just fundamentally C-hostile. Perhaps the most famous one is 6502. No efficient way to implement stack based parameter passing, generic pointer arithmetic, and lots of other bits and pieces. You can still use C on 6502, it's just not very fast. I guess you could define another language that mostly looks like C, but built around particular CPU architecture quirks.
- wwweston 7y agoWhat are some languages (other than its own instructions) that 6502 is friendly to?
- pvg 7y agoBASIC, arguably. People often say C is 'high level assembly' but in some ways BASIC is closer with the absence of block structure, scopes, etc. Control flow in a BASIC (basic BASIC, not fancy newer BASIC) program ends up looking a lot like that in an assembly one.
- int_19h 7y agoGiven that all that high-level control flow is rewritten into gotos anyway, why would that make a difference in general, or specifically for 6502?
- Tuna-Fish 7y agoAll high-level control flow is very definitely not rewritten into gotos. Almost all cpus have some form of function call instruction, and c functions are implemented by using it. Without such an instruction, or even a fast way to model it, C becomes much less efficient to implement.
- int_19h 7y agoOP was talking about block structure, not subprograms. In any case, BASIC has them.
- wk_end 7y agoFORTH was pretty widely used on 6502-based machines.
- TazeTSchnitzel 7y agoI wonder if you can write fast C for the 6502, though, but you'll have to constrain your use of the language considerably?
- spc476 7y agoThe 6502 is a very constrained CPU. It only has 6 registers, only one of which (PC) is 16 bits. The stack is fixed at addresses 0x0100 to 0x01FF, and the two index registers are 8-bits in size. So is the accumulator and the stack register (hence the fixed address for the system stack) and no stack-based addressing modes. You'll have a severe penalty in doing any 16-bit arithmetic. There is no general multiply or divide instructions. I think the architecture is about as hostile to C as you can get and still be popular.
- bsder 7y agoThe main problem is that most compilers really need lots of registers to optimize well. Without lots of registers, you're constantly spilling to memory and that makes things slow. If you program in assembly, you have visceral knowledge of when you overrun you registers and you will restructure the entire architecture of your program to avoid that.
- tdons 7y agoBen Eater has a fantastic series of videos where he builds a hello world program on the 6502 https://www.youtube.com/watch?v=LnzuMJLZRdU&list=PLowKtXNTBypFbtuVMUVXNR0z1mu7dp7eH https://www.youtube.com/watch?v=LnzuMJLZRdU&list=PLowKtXNTBy...
- Someone 7y agoI think that, partly, that it isn’t as much C-hostile as that C compilers mostly target other architectures, and that many C programs take too much for granted, such as the existence of huge 16-bit Numbers or efficient multiplication. A compiler/linker combo for the 6502 should, for example, analyse the call graph of the entire program to figure out what return addresses it needs to store on the stack at all (alternative 1: store it at a forced address in main memory (will work in single-threaded code that isn’t recursive). Alternative 2: instead of RTS, jump back to the caller (will work for functions that get called from only one place. Aggressively inlining those is an alternative, but may turn short branches into long ones, with their own problems) Similarly, a compiler/linker for the 6502 probably should try really hard to move function arguments to fixed addresses, and to reuse such memory between different functions (if foo isn’t (indirectly) recursive and doesn’t (indirectly) call bar and vice versa, their function arguments can share memory) And yes, self-hosting such a compiler would be even more challenging, given the 64kB memory limit.
- fpoling 7y agoSounds like it was targeting Fortran.