Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

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.

View on HN

There 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.

What are some languages (other than its own instructions) that 6502 is friendly to?

BASIC, 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.

Given that all that high-level control flow is rewritten into gotos anyway, why would that make a difference in general, or specifically for 6502?

All 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.

OP was talking about block structure, not subprograms. In any case, BASIC has them.

FORTH was pretty widely used on 6502-based machines.

I wonder if you can write fast C for the 6502, though, but you'll have to constrain your use of the language considerably?

The 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.

The 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.

Ben 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=PLowKtXNTBy...

I 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.

Sounds like it was targeting Fortran.

Reply on news.ycombinator.com