Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Didn't John Carmack use structures rather than parallel arrays even in Apple II assembly? Source: one of his old .plan files, reproduced verbatim in _Masters of Doom_

Edit: Found it online here: https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...



I wrote a few lines about 6502 vs Z80 a couple of years ago: https://news.ycombinator.com/item?id=10766264 (parent of linked-to comment may also be of interest) - the discussion there was about relative efficiency of the two CPUs, but the addressing mode limitations that make one approach a bit inefficient on the 6502 are the same limitations that make it a bit inconvenient.

I wonder what Carmack had in mind.

---

P.S. In my comment there, I didn't mention the possibility of having the arrays interleaved. Then it looks like a struct in memory (byte 0 is X and byte is DX, say), and you add the field offset to the base of the array. It's not uncommon for assemblers to have some syntax to make it easy to specify the layout of each struct, to simplify future changes, e.g.:

    STRUCT ITEM
    X DS.B 1
    DX DS.B 1
    ENDSTRUCT

    CLC
    LDA TABLE+ITEM.X,X
    ADC TABLE+ITEM.DX,X
    STA TABLE+ITEM.X,X
    LDA #0
    STA TABLE+ITEM.DX,X
The disadvantages of this are that it reduces the number of accessible items (the X register is only 8 bits...); it makes moving from item to item more difficult (all you can do with the X register is increment or decrement it, but now you need to add arbitrary values to it); and it means there are invalid item indexes (e.g., in the example above, index 1 is not valid).

And the advantages... well, there aren't any, really, I don't think? Everything has to be done 1 byte at a time, so it makes no difference where the bytes are relative to one another... the code ends up the same anyway. (If anything, because you can do INX/DEX to get from item to item, it's actually slightly neater to have a separate table for each byte.) So you might as well do that.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: