Hacker News Reader

Comment by kken | Hacker News Reader

Well, the 6502 is simply not made to be programmed in a high level language.

Note that there are many instructions that simply don't map to high level language features, such as bit rotation (not shift!), BCD mode and indirectly indexed adressing.

One thing that it very popular in highly optimized 6502 assembler code is self-manipulating code or even run-time generated code. This allows to work around a lot of limitations with indexed adressing or parameter loading.

The 6502 was designed at a time when CPUs were not limited by memory speed. I imagine that has only been the case right after the emergence of the first MOS-Memory (Intel, late 60ies)

Edit: For those interested in state of the art optimized 6502 arithmetic, this is a very good source:

http://codebase64.org/doku.php?id=base:6502_6510_maths

View on HN

This reminds me, why do most high-level languages lack a bit rotation operator?

It's an operation that is required in some cases, and it can easily be emulated by the compiler for targets which lack it. However deducing that you're trying to do bit rotation and emitting the CPU instruction when present is not easy for the compiler.

> However deducing that you're trying to do bit rotation and emitting the CPU instruction when present is not easy for the compiler.

Uh, no. a rotate_left b is equivalent to a << b | a >>> (sizeof_in_bits(a) - b). As far as common instructions not present in language standards go, regular rotates are the easiest for the compiler to recognize.

Well then, I've must have been using the wrong compilers, as they did not output the rol/ror instruction last I tried.

edit: For example, VS2017 x86 target does not output rol instruction for your code with /O1.

Ah, it does it with 32bit operands but not 8bit. That must be why I missed it.

C programmers have the worst time with this; your compilers are so unextensible and opaque. Here's an example of extending the SBCL compiler to support a new instruction: https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrins...

Can you show your code for 8 bit case that fails to generate rol?

Seems I must have messed something up in the initial testing. Now it outputs rol with uint8_t too. Well, that's good to know.

For the record, here was what I was testing:

  #include <iostream>

  uint8_t rol(uint8_t x, uint8_t c) {
  	return (x << c | x >> (sizeof(x) * 8 - c));
  }
  
  int main()
  {
  	volatile uint8_t a = 0b01010000;
  	volatile uint8_t b = 3;
  
  	uint8_t c = rol(a, b);
  
  	std::cout << static_cast<unsigned int>(0b10000010) << std::endl;
  	std::cout << static_cast<unsigned int>(c) << std::endl;
  
  	return 0;
  }

Still I wonder, why go through this guesswork in order to try to figure out what the user wants, instead of having an operator which clearly states what the user wants?

I always wondered if the PDP-11 (which c was originally developed on) was missing rotate instructions.

Weirdly enough, it does have rotate instructions. Even weirder, there is no logical shift right instruction on the PDP-11. The original c compiler must have been emulating one by clearing the carry bit beteen rotates.

C came from B, which predated the PDP-11.

https://www.bell-labs.com/usr/dmr/www/chist.html

Especially on microcontrollers or DSPs this could be quite useful. I have never seen a C-compiler able to infer a bit rotation instruction, though.

gcc will recognize the usual rotate idiom:

    unsigned int rotv(unsigned int x, int c) {
        return (x << c) | (x >> (32 - c));
    }

On x86 it emits a rol instruction, for instance.

The original ARM C compiler ('Norcroft') did this a lot as I recall.

Relevant to the original post here of course, as the original spec was a processor that could interpret BBC BASIC as fast as hand optimised 6502 assembler.

... and yet people successfully programmed 6502 machines, including one explicitly mentioned in the headlined article, in languages such as BASIC.

And those BASIC interpreters were extremely slow. Clearly there are many interpreters and compilers for the 6502 and almost every other CPU architecture ever designed. Nobody said it's impossible to program the 6502 in high level languages, the architecture is just not designed to be a compiler/interpreter target and it is basically impossible to map many high level language constructs to efficient 6502 code.

There is an important difference: BASIC is interpreted, not compiled.

You are erroneously conflating high level and compiled. Or you are not reading what you yourself actually wrote.

I imagine that 'programming the 6502' here refers to somehow creating code that the CPU executes directly, and so interpreted languages are automatically excluded.

C64 had BASIC compilers back in the day.

Reply on news.ycombinator.com