6 ms·

68000 Tricks and Traps – Some assembly language programming guidelines (1986)

82 points by rocky1138 9y ago

AnimalMuppet 9y ago
Note: 1986 Ah, what wonderful chips the 68000 series were, at least for the era. So many registers, such a nice clean architecture. Good times.
- Symmetry 9y ago
  The idea of having separate data and address registers is a really interesting one. I've heard that the only pain point was not being able to take the difference between two addresses quickly.
  - JKCalhoun 9y ago
    I'm wondering why you would want to do that anyway?
    - mikepavone 9y ago
      To make the encoding more compact while still having a large number of registers. A normal arithmetic instruction will have two 3-bit register fields, 1 3-bit effective address type field, and 3-bits that determine the size and direction (i.e. whether the effective address is the source or destination operand). Since an instruction word is 16-bits, this leaves 4-bits to select the operation type. This is a bit of a simplification as some instructions have more restrictions and move instructions are more expressive, but you get the idea. Having a flat 16 register file would require two extra register bits in most instructions which would either halve the number of possible operations or require bits to be removed elsewhere. Since the operations required on pointers is typically much smaller than those required on non-pointer integers, this setup makes a certain amount of sense. The big downside is that as ajross points out, it complicates register allocation in a way that just about no other "mainstream" architecture does. Other tradeoffs (larger instruction word, fewer addressing modes on "normal" instructions, requiring an extension word for more addressing modes, etc.) could have produced a cleaner architecture at the expense of code density. Code density was a big deal in the late 70's when the 68000 was designed due to the cost of memory. EDIT: A flat 16 register file would actually quarter, not halve, the number of operation types since you lose 1-bit per register field.
      - adrianmonk 9y ago
        Maybe they're asking why you'd want to subtract addresses. Unclear though.
      - JKCalhoun 9y ago
        Sorry, yes, like the other poster said, I was wondering what you would want to subtract addresses.
        mikepavone 9y ago
        Say you have a pointer to the start of an array and a pointer to a certain element and you want to turn that into an index. Not super common, but not a crazy special case either. I'm not sure why the other poster thought this was a limitation on the 68000 though as subtraction is one of the few arithmetic operations you can perform on address registers. Perhaps he/she confused the limitations of the AU (address unit) with limitations on address registers? The AU is used for calculating effective addresses and all it can do is add; however, normal add and sub instructions use the ALU even when working exclusively with address registers. There are a bunch of other operations that you can't do on address registers (or at the very least, an address register can only be used for the effective address operand). This can be inconvenient if your code needs a bunch of registers, but not very many pointers. Not a huge deal otherwise.
    - vidarh 9y ago
      To calculate the size of a structure, or the offset of a substructure. But you can do that on the M68k: SUBA.L <ea>,An <ea> can be any addressing mode, including another address register. Most assemblers will let you use SUB.L and substitute SUBA if the destination is an address register.
  - ajross 9y ago
    Not the only pain point. It made register assignment harder for the compiler. Fundamentally you load from memory in generated code by adding two numbers together (e.g. the struct address and field offset, array address and index...). Motorola figured that you could just pick one number from each of two sets and thus save two bits (i.e. the source registers could be encoded with 3 bits instead of 4) in the encoding for the instruction. As far as CISC tricks go, it wasn't too bad. But it's aged poorly: no one would design a ISA like that today, while Intel's elaborate addressing modes introduced with the 386 are producing code size and cache efficiency benefits to this very day.
    - jacquesm 9y ago
      > while Intel's elaborate addressing modes introduced with the 386 are producing code size and cache efficiency benefits to this very day. At the expense of orthogonality, which I think is a great feature for a CPU to have and which the 68K (and 6809 and 6800) had in spades.
      - yongjik 9y ago
        Hmm, wasn't the 386 addressing modes pretty much orthogonal? (At least, compared to what 8086 and 80286 had.)
        jacquesm 9y ago
        Yes, but the instruction set wasn't. Orthogonality in an instruction set basically means that you know what basic instructions a processor supports, which addressing modes it supports and that allows you to create all possible combinations and they will just work as expected without gaps or strange insertions and if you look at the opcodes you'll be able to make sense of them.
    - puzzle 9y ago
      Didn't the 68020 add even more addressing modes, plus scaling? Comparing the 68000 to the 386 doesn't seem too fair.
  - pklausler 9y ago
    FWIW, the CDC 6600 and Cray instruction set architectures also had this address vs. data distinction in their (scalar) register files. Both could do basic integer operations, but only the address registers could be used for address calculations in load/store instructions, while only the data registers could do floating-point. (Strictly speaking, the CDC 6600 didn't have load/store instructions per se. Instead, any time you modified address registers A1-A5, a load to the corresponding data register X1-X5 took place from the resulting address. Modifications to A6-A7 caused a store from X6-X7 to the resulting address. It made for such tight code!)
  - vidarh 9y ago
    SUBA.L will let you subtract a an address register from another (you can use any effective address as the source operand).
- Steve44 9y ago
  I really loved programming it. The Z80 was nice and concise but quite restrictive, 68k really opened up with addressing modes and registers. I've had a quick scan through that page and recognise most of them from the dim distant past. One thing I didn't see mentioned is it had a small instruction pipeline so we could squeeze better performance out of it by by careful instruction sequence. For example you wouldn't load a register and then use in in the next instruction because it wouldn't be ready and could stall. By what is effectively interleaving code where possible you could keep it running flat out. Every cycle matters!
  - vidarh 9y ago
    The 68010 had a special mode to accelerate tight loops, but first the 68020 added a proper pipeline. The 68000 had neither.
- ENTP 9y ago
  68k, Atari ST, DevPac. Some of the funnest coding ever. When i discovered x86 ~10 years later I was horrified at how shit it was.
TheRealPomax 9y ago
I feel cheated, there were way fewer than 68000 tricks and traps in this article.
znpy 9y ago
Easy68k. I have hated that program with passion during the computer architecture course. Didn't know how and why, but various conditional jumps used to plain fail. Conditions were met, but the jmp/je/jne/jz would not be executed. That being said... The m68k... I was saddened to discover thst coldfire mcus had been discontinued, it would have been nice to play with an m68k-based board.
- kevin_thibedeau 9y ago
  You can implement a 68k in an FPGA with plenty of room to spare.
- RJIb8RBYxzAMX9u 9y ago
  ColdFire development boards by Freescale / NXP are still readily available, and relatively inexpensive. Not that I would recommend you start any new projects based on CF, but for the cost of ~3 RasPis, you get buy an evaluation board from DigiKey, and play to your heart's content.
- Gracana 9y ago
  If you're looking for a nice CISC architecture to replace m68k, I recommend the Renesas RX family. There's a lot of options, availability is good, and the ISA is assembly-pogrammer-friendly. https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_family/r01us0032ej0120_rxsm.pdf https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_fam...
  - Taniwha 9y ago
    Yes it totally time for an assemply language pogrom
rangibaby 9y ago
> Trick and Traps MAP08 name inspiration? It's old enough
freedomben 9y ago
This tickles my nostalgia from the days of TI Calculator ASM hacking
- alxmdev 9y ago
  Indeed! I started with C by following the TIGCC TI-89 tutorials from http://www.technoplaza.net/ http://www.technoplaza.net/ long ago, and since I got an Arduboy I've been itching to dive back into calc stuff and try some small assembly gamedev. So many little projects worth doing and so little time!

82 points by rocky1138 9y ago

Note: 1986 Ah, what wonderful chips the 68000 series were, at least for the era. So many registers, such a nice clean architecture. Good times.

Symmetry 9y ago
The idea of having separate data and address registers is a really interesting one. I've heard that the only pain point was not being able to take the difference between two addresses quickly.
- JKCalhoun 9y ago
  I'm wondering why you would want to do that anyway?
  - mikepavone 9y ago
    To make the encoding more compact while still having a large number of registers. A normal arithmetic instruction will have two 3-bit register fields, 1 3-bit effective address type field, and 3-bits that determine the size and direction (i.e. whether the effective address is the source or destination operand). Since an instruction word is 16-bits, this leaves 4-bits to select the operation type. This is a bit of a simplification as some instructions have more restrictions and move instructions are more expressive, but you get the idea. Having a flat 16 register file would require two extra register bits in most instructions which would either halve the number of possible operations or require bits to be removed elsewhere. Since the operations required on pointers is typically much smaller than those required on non-pointer integers, this setup makes a certain amount of sense. The big downside is that as ajross points out, it complicates register allocation in a way that just about no other "mainstream" architecture does. Other tradeoffs (larger instruction word, fewer addressing modes on "normal" instructions, requiring an extension word for more addressing modes, etc.) could have produced a cleaner architecture at the expense of code density. Code density was a big deal in the late 70's when the 68000 was designed due to the cost of memory. EDIT: A flat 16 register file would actually quarter, not halve, the number of operation types since you lose 1-bit per register field.
    - adrianmonk 9y ago
      Maybe they're asking why you'd want to subtract addresses. Unclear though.
    - JKCalhoun 9y ago
      Sorry, yes, like the other poster said, I was wondering what you would want to subtract addresses.
      - mikepavone 9y ago
        Say you have a pointer to the start of an array and a pointer to a certain element and you want to turn that into an index. Not super common, but not a crazy special case either. I'm not sure why the other poster thought this was a limitation on the 68000 though as subtraction is one of the few arithmetic operations you can perform on address registers. Perhaps he/she confused the limitations of the AU (address unit) with limitations on address registers? The AU is used for calculating effective addresses and all it can do is add; however, normal add and sub instructions use the ALU even when working exclusively with address registers. There are a bunch of other operations that you can't do on address registers (or at the very least, an address register can only be used for the effective address operand). This can be inconvenient if your code needs a bunch of registers, but not very many pointers. Not a huge deal otherwise.
  - vidarh 9y ago
    To calculate the size of a structure, or the offset of a substructure. But you can do that on the M68k: SUBA.L <ea>,An <ea> can be any addressing mode, including another address register. Most assemblers will let you use SUB.L and substitute SUBA if the destination is an address register.
- ajross 9y ago
  Not the only pain point. It made register assignment harder for the compiler. Fundamentally you load from memory in generated code by adding two numbers together (e.g. the struct address and field offset, array address and index...). Motorola figured that you could just pick one number from each of two sets and thus save two bits (i.e. the source registers could be encoded with 3 bits instead of 4) in the encoding for the instruction. As far as CISC tricks go, it wasn't too bad. But it's aged poorly: no one would design a ISA like that today, while Intel's elaborate addressing modes introduced with the 386 are producing code size and cache efficiency benefits to this very day.
  - jacquesm 9y ago
    > while Intel's elaborate addressing modes introduced with the 386 are producing code size and cache efficiency benefits to this very day. At the expense of orthogonality, which I think is a great feature for a CPU to have and which the 68K (and 6809 and 6800) had in spades.
    - yongjik 9y ago
      Hmm, wasn't the 386 addressing modes pretty much orthogonal? (At least, compared to what 8086 and 80286 had.)
      - jacquesm 9y ago
        Yes, but the instruction set wasn't. Orthogonality in an instruction set basically means that you know what basic instructions a processor supports, which addressing modes it supports and that allows you to create all possible combinations and they will just work as expected without gaps or strange insertions and if you look at the opcodes you'll be able to make sense of them.
  - puzzle 9y ago
    Didn't the 68020 add even more addressing modes, plus scaling? Comparing the 68000 to the 386 doesn't seem too fair.
- pklausler 9y ago
  FWIW, the CDC 6600 and Cray instruction set architectures also had this address vs. data distinction in their (scalar) register files. Both could do basic integer operations, but only the address registers could be used for address calculations in load/store instructions, while only the data registers could do floating-point. (Strictly speaking, the CDC 6600 didn't have load/store instructions per se. Instead, any time you modified address registers A1-A5, a load to the corresponding data register X1-X5 took place from the resulting address. Modifications to A6-A7 caused a store from X6-X7 to the resulting address. It made for such tight code!)
- vidarh 9y ago
  SUBA.L will let you subtract a an address register from another (you can use any effective address as the source operand).
Steve44 9y ago
I really loved programming it. The Z80 was nice and concise but quite restrictive, 68k really opened up with addressing modes and registers. I've had a quick scan through that page and recognise most of them from the dim distant past. One thing I didn't see mentioned is it had a small instruction pipeline so we could squeeze better performance out of it by by careful instruction sequence. For example you wouldn't load a register and then use in in the next instruction because it wouldn't be ready and could stall. By what is effectively interleaving code where possible you could keep it running flat out. Every cycle matters!
- vidarh 9y ago
  The 68010 had a special mode to accelerate tight loops, but first the 68020 added a proper pipeline. The 68000 had neither.
ENTP 9y ago
68k, Atari ST, DevPac. Some of the funnest coding ever. When i discovered x86 ~10 years later I was horrified at how shit it was.

TheRealPomax 9y ago

I feel cheated, there were way fewer than 68000 tricks and traps in this article.

znpy 9y ago

Easy68k. I have hated that program with passion during the computer architecture course. Didn't know how and why, but various conditional jumps used to plain fail. Conditions were met, but the jmp/je/jne/jz would not be executed. That being said... The m68k... I was saddened to discover thst coldfire mcus had been discontinued, it would have been nice to play with an m68k-based board.

kevin_thibedeau 9y ago
You can implement a 68k in an FPGA with plenty of room to spare.
RJIb8RBYxzAMX9u 9y ago
ColdFire development boards by Freescale / NXP are still readily available, and relatively inexpensive. Not that I would recommend you start any new projects based on CF, but for the cost of ~3 RasPis, you get buy an evaluation board from DigiKey, and play to your heart's content.
Gracana 9y ago
If you're looking for a nice CISC architecture to replace m68k, I recommend the Renesas RX family. There's a lot of options, availability is good, and the ISA is assembly-pogrammer-friendly. https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_family/r01us0032ej0120_rxsm.pdf https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_fam...
- Taniwha 9y ago
  Yes it totally time for an assemply language pogrom

rangibaby 9y ago

> Trick and Traps MAP08 name inspiration? It's old enough

freedomben 9y ago

This tickles my nostalgia from the days of TI Calculator ASM hacking

alxmdev 9y ago
Indeed! I started with C by following the TIGCC TI-89 tutorials from http://www.technoplaza.net/ http://www.technoplaza.net/ long ago, and since I got an Arduboy I've been itching to dive back into calc stuff and try some small assembly gamedev. So many little projects worth doing and so little time!