Hacker News Reader

A language lawyer quiz: if the definition is changed to

    uint16_t mem[UINT16_MAX + 1] = {0};

is it guaranteed to work on platforms where unsigned int is 16-bit wide? What about platforms where void* is 16-bit wide (hint: &mem[65536] must be a valid pointer value that must compare unequal from &mem[0])?

> &mem[65536] must be a valid pointer value

explain

C99 draft, 6.5.6.8:

    Moreover, if the expression P points to the last element of an array object, 
    the expression (P)+1 points one past the last element of the array object,
    and if the expression Q points one past the last element of an array object,
    the expression (Q)-1 points to the last element of the array object. If both
    the pointer operand and the result point to elements of the same array object,
    or one past the last element of the array object, the evaluation shall not
    produce an overflow; otherwise, the behavior is undefined. If the result points
    one past the last element of the array object, it shall not be used as the
    operand of a unary * operator that is evaluated.

> Personally, I prefer having a switch since it's more obvious which opcode goes where.

In practice, having a switch is not worse or can even be better for performance because any non-naive optimising compiler will emit a nicely ordered indexed jump table, whereas following function pointers involves more indirection through the addresses of the functions, and has the additional overhead of passing args and preparing/restoring the stack.

I've thought of that, and to be honest I think it's worth mentioning in the article. But having set this arbitrary limit to 125 lines, before even starting to sketch things down, made me use the function tables. As a plus, article is intended for beginners, and it would be cool if they learn about function pointers from a practical example.

But from a performance perspective, you are right!

There's also "computed gotos". It's not the same as function pointers, though.

https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e... - article about them being used in CPython

Gforth uses the same trick. https://www.complang.tuwien.ac.at/forth/threaded-code.html

Further to this: this kind of thing is something the Forth community takes seriously. They call these threaded code techniques. [0] (The Gforth interpreter, for instance, gives you the choice of various different techniques.)

Anton Ertl of Gforth fame published a microbenchmark performance comparison of toy interpreters, written in C, run on various CPUs. [1] As you say, the approach using function pointers (call threading) scores poorly.

Interestingly, direct threading and indirect threading are extremely close, with the winner seeming to depend on the specific CPU. [1] Branch-prediction differences seem to be the main reason. There was a 2001 paper on this. [2]

[0] https://www.complang.tuwien.ac.at/forth/threaded-code.html

[1] https://www.complang.tuwien.ac.at/forth/threading/

[2] https://github.com/ForthPapersMirror/Papers/blob/master/Conv...

The real problem solved by BWX wasn't shifting and masking necessary in handling 8-bit values, as that was handled pretty transparently by compilers, it was how complicated it made dealing with hardware I/O which often expected 8bit or 16bit atomic writes - whereas Alpha could not do shorter i/o than halfword, i.e. 32 bits (All I/O on Alpha was MMIO).

This is visible in form of big split in Alpha hw support (drivers etc) on VMS and OSF/1 between "non-BWX" and "BWX" hardware.

> without byte-wide memory access, you'll quickly realise how annoying it is to work with actual bytes. For example, any string handling, unless you decide to use UTF-16 instead. I think a sweet spot is 16-bit address and 8-bit data

Even if you don't want to call it UTF-16, you can just ignore the upper byte of your 16-bit cells and pretend they only store bytes when that's more convenient for you: for practical purposes you won't end up with any less memory available than if your cells were only 8 bits wide, but you have the option of using more when you need it.