6 ms·

Motorola 68k Application Binary Interface (ABI)

63 points by mshockwave 5y ago

cmrdporcupine 5y ago
It's great to see the 68k backends of GCC and LLVM getting love again. In many respects the 68000 is the oldest most "retro" architecture for which you can still run a modern compiler suite. Processor introduced in 1979 for which you could compile a Rust binary today. That's pretty amazing.
- jagrsw 5y ago
  The ISA is really beautiful (maybe with the exception of BCD additions). I have a m68k disk image/kernel which works with qemu-system-m68k, out of historical sentiment (used to have A500, now I have A4000 - sadly no time to play with it, so in my basement). As for abi/syscalls. I noticed that strace reports hundreds of calls to get_thread_area() under Linux/m68k. I presume under x86, arm etc. some CPU register is used to store pointer to the TLS, but under m68k "they" decided to invoke syscall every single time. I don't think it'd be very efficient, and also it pollutes strace output, unfortunately, given how frequently TLS is accessed these days. $ uname -a Linux ds-m68k 5.16.0-rc1-g02e0dceb9e3b #7 Fri Jan 14 01:27:22 CET 2022 m68k GNU/Linux $ strace -c /bin/ls % time seconds usecs/call calls errors syscall ---- ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 6 read 0.00 0.000000 0 1 write 0.00 0.000000 0 10 close 0.00 0.000000 0 1 execve 0.00 0.000000 0 2 2 access 0.00 0.000000 0 3 brk 0.00 0.000000 0 3 ioctl 0.00 0.000000 0 1 munmap 0.00 0.000000 0 2 2 statfs 0.00 0.000000 0 1 uname 0.00 0.000000 0 10 mprotect 0.00 0.000000 0 14 mmap2 0.00 0.000000 0 2 getdents64 0.00 0.000000 0 8 openat 0.00 0.000000 0 285 get_thread_area 0.00 0.000000 0 1 set_thread_area 0.00 0.000000 0 9 statx ---- ----------- ----------- --------- --------- ---------------- 100.00 0.000000 0 359 4 total
  - jandrese 5y ago
    Maybe that is a form of exploit mitigation? Maybe they can't cache the TLS pointer because the kernel may change it out from under you without warning? I do agree that it smells like a possible performance issue and it seems like there must be a better way to do it.
    - jagrsw 5y ago
      From https://lists.debian.org/debian-68k/2007/11/msg00071.html https://lists.debian.org/debian-68k/2007/11/msg00071.html (Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2) There are no spare registers available to designate as the thread register. Therefore, kernel magic is needed to obtain the thread pointer from userspace. I guess there was unused 'fs' in intel. There was nothing left in m68k.
      - jandrese 5y ago
        This doesn't really answer the question. Even if there isn't a free register the value could be stored on the stack and avoid the syscall overhead. Or maybe I'm misunderstanding what that variable is doing. Or at the very least the value could be calculated once via the kernel and then cached in main memory/a general purpose register.
        jagrsw 5y ago
        I'm speculating heavily here, but it seems TLS seems to be userland thing, but with OS support (e.g. CLONE_SETTLS flags, *_thread_area()). Maybe it was thought more like a thread-level thing, and not runtime thing. E.g. if we had some competing runtimes in one process space (e.g. go, jvm, libc), then they can all obtain TLS pointer via some unified method (via register or syscall). Otherwise there would be need for some chosen runtime, which would keep the pointer and distribute it around - which would create another set of problems. Putting it on the top of initial process stack would work I guess, though.
        johntb86 5y ago
        The value is per thread, so if you're caching it to main memory (including in the stack) then you need one copy per thread and you need to somehow know which one to use based on what thread is running. You'd need to store that index somewhere so there'd be an infinite recursion. Even if it's stored at the base of the current stack you don't want to have to walk all the stack frames to find it. You can store it in a GPR instead (that's what some modern architectures do) but then it needs to be part of the ABI. Otherwise at the beginning of a function you can't assume any register contains the correct value.
gmueckl 5y ago
The 68k series are rather simple designs by today's standard and should be old enough to have lost patent protection. How hard would it be to reimplement the ISA as a Verilog/VHDL softcore?
- gpderetta 5y ago
  It has been done. Search for the Apollo 68080 for example. edit: also relevant is the the PiStorm, a software emulated 680x0 running on a RaspberryPi that plugs into a 680x0 socket. edit2: the MiST/MiSTer are also well known 680x0 open source FPGA implementations.
herio 5y ago
The AmigaOS ABI was really designed for the m68k, it leverages registers as much as possible. Pass variables in data registers, pointers in address registers. A4 for local data, A6 for the library pointer, results in D0. That said, most library routines would then store the register contents on the stack and restore on return so not sure it's more efficient for memory access etc. The m68k is the most CISC of ISAs I've seen, you have plentiful addressing modes and register orthogonality. It had adressing modes to do auto postincrements/predecrements, indirect indexed accesses and all sorts of fun.
mrlonglong 5y ago
It would be nice to see the m68k get some 64 bit love to bring it right up to date. I've been considering what such a beast could look like compared to the cruddy x86 64 bit ISA.
- cmrdporcupine 5y ago
  The moment you start doing that you are going to lose backwards compatibility anyways, so may as well go back to the drawing board and revisit other compromises made in the ISA (like separate data and address registers, for example. Or big endian instead of little endian) and you end up with something else, IMHO. Maybe something closer to a 64-bit version of the NS32k ISA.
  - KerrAvon 5y ago
    Those changes would lose the character of the M68k, though.
    - mrlonglong 5y ago
      Yes, the instruction set is laid out rather beautifully, this is something I'd really like to see to implemented in 64 bits with support for true SMP and see how well that performs against other architectures.
      - cmrdporcupine 5y ago
        It's a nice CISC, but the two separate register files are something you'd be silly to carry over to 64-bit. I think the lesson from x86 is that it's entirely possible to make a legacy CISC ISA perform really well with enough engineering. But the question is: why do that for an extinct arch? Only 32-bits, but ColdFire attempted to revive the ISA and that didn't work out, either.
        mrlonglong 5y ago
        I think we would apply the lessons learned since the 90s and see where that gets us.
deleted 5y ago
[deleted]
jerrysievert 5y ago
I really miss my copy of the m68k programmers reference manual. when I finally had to learn x86, I remember being so frustrated at how fractured it was compared to the beauty that was m68k at the time.
- mshockwave 5y ago
  I think you're talking about this one? https://m680x0.github.io/doc/official-docs https://m680x0.github.io/doc/official-docs
  - jerrysievert 5y ago
    I was actually talking about this one (sorry about the amazon link): https://www.amazon.com/M68000-16-bit-microprocessor-Programmers-reference/dp/013566795X https://www.amazon.com/M68000-16-bit-microprocessor-Programm... much more blue cover - I think I kept it until about 10 years ago, when I did a purge of physical books that didn't have a fairly deep sentimental attachment. of course, that still ended up with hundreds of pounds of paper.

63 points by mshockwave 5y ago

It's great to see the 68k backends of GCC and LLVM getting love again. In many respects the 68000 is the oldest most "retro" architecture for which you can still run a modern compiler suite. Processor introduced in 1979 for which you could compile a Rust binary today. That's pretty amazing.

jagrsw 5y ago
The ISA is really beautiful (maybe with the exception of BCD additions). I have a m68k disk image/kernel which works with qemu-system-m68k, out of historical sentiment (used to have A500, now I have A4000 - sadly no time to play with it, so in my basement). As for abi/syscalls. I noticed that strace reports hundreds of calls to get_thread_area() under Linux/m68k. I presume under x86, arm etc. some CPU register is used to store pointer to the TLS, but under m68k "they" decided to invoke syscall every single time. I don't think it'd be very efficient, and also it pollutes strace output, unfortunately, given how frequently TLS is accessed these days. $ uname -a Linux ds-m68k 5.16.0-rc1-g02e0dceb9e3b #7 Fri Jan 14 01:27:22 CET 2022 m68k GNU/Linux $ strace -c /bin/ls % time seconds usecs/call calls errors syscall ---- ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 6 read 0.00 0.000000 0 1 write 0.00 0.000000 0 10 close 0.00 0.000000 0 1 execve 0.00 0.000000 0 2 2 access 0.00 0.000000 0 3 brk 0.00 0.000000 0 3 ioctl 0.00 0.000000 0 1 munmap 0.00 0.000000 0 2 2 statfs 0.00 0.000000 0 1 uname 0.00 0.000000 0 10 mprotect 0.00 0.000000 0 14 mmap2 0.00 0.000000 0 2 getdents64 0.00 0.000000 0 8 openat 0.00 0.000000 0 285 get_thread_area 0.00 0.000000 0 1 set_thread_area 0.00 0.000000 0 9 statx ---- ----------- ----------- --------- --------- ---------------- 100.00 0.000000 0 359 4 total
- jandrese 5y ago
  Maybe that is a form of exploit mitigation? Maybe they can't cache the TLS pointer because the kernel may change it out from under you without warning? I do agree that it smells like a possible performance issue and it seems like there must be a better way to do it.
  - jagrsw 5y ago
    From https://lists.debian.org/debian-68k/2007/11/msg00071.html https://lists.debian.org/debian-68k/2007/11/msg00071.html (Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2) There are no spare registers available to designate as the thread register. Therefore, kernel magic is needed to obtain the thread pointer from userspace. I guess there was unused 'fs' in intel. There was nothing left in m68k.
    - jandrese 5y ago
      This doesn't really answer the question. Even if there isn't a free register the value could be stored on the stack and avoid the syscall overhead. Or maybe I'm misunderstanding what that variable is doing. Or at the very least the value could be calculated once via the kernel and then cached in main memory/a general purpose register.
      - jagrsw 5y ago
        I'm speculating heavily here, but it seems TLS seems to be userland thing, but with OS support (e.g. CLONE_SETTLS flags, *_thread_area()). Maybe it was thought more like a thread-level thing, and not runtime thing. E.g. if we had some competing runtimes in one process space (e.g. go, jvm, libc), then they can all obtain TLS pointer via some unified method (via register or syscall). Otherwise there would be need for some chosen runtime, which would keep the pointer and distribute it around - which would create another set of problems. Putting it on the top of initial process stack would work I guess, though.
      - johntb86 5y ago
        The value is per thread, so if you're caching it to main memory (including in the stack) then you need one copy per thread and you need to somehow know which one to use based on what thread is running. You'd need to store that index somewhere so there'd be an infinite recursion. Even if it's stored at the base of the current stack you don't want to have to walk all the stack frames to find it. You can store it in a GPR instead (that's what some modern architectures do) but then it needs to be part of the ABI. Otherwise at the beginning of a function you can't assume any register contains the correct value.

gmueckl 5y ago

The 68k series are rather simple designs by today's standard and should be old enough to have lost patent protection. How hard would it be to reimplement the ISA as a Verilog/VHDL softcore?

gpderetta 5y ago
It has been done. Search for the Apollo 68080 for example. edit: also relevant is the the PiStorm, a software emulated 680x0 running on a RaspberryPi that plugs into a 680x0 socket. edit2: the MiST/MiSTer are also well known 680x0 open source FPGA implementations.

herio 5y ago

The AmigaOS ABI was really designed for the m68k, it leverages registers as much as possible. Pass variables in data registers, pointers in address registers. A4 for local data, A6 for the library pointer, results in D0. That said, most library routines would then store the register contents on the stack and restore on return so not sure it's more efficient for memory access etc. The m68k is the most CISC of ISAs I've seen, you have plentiful addressing modes and register orthogonality. It had adressing modes to do auto postincrements/predecrements, indirect indexed accesses and all sorts of fun.

mrlonglong 5y ago

It would be nice to see the m68k get some 64 bit love to bring it right up to date. I've been considering what such a beast could look like compared to the cruddy x86 64 bit ISA.

cmrdporcupine 5y ago
The moment you start doing that you are going to lose backwards compatibility anyways, so may as well go back to the drawing board and revisit other compromises made in the ISA (like separate data and address registers, for example. Or big endian instead of little endian) and you end up with something else, IMHO. Maybe something closer to a 64-bit version of the NS32k ISA.
- KerrAvon 5y ago
  Those changes would lose the character of the M68k, though.
  - mrlonglong 5y ago
    Yes, the instruction set is laid out rather beautifully, this is something I'd really like to see to implemented in 64 bits with support for true SMP and see how well that performs against other architectures.
    - cmrdporcupine 5y ago
      It's a nice CISC, but the two separate register files are something you'd be silly to carry over to 64-bit. I think the lesson from x86 is that it's entirely possible to make a legacy CISC ISA perform really well with enough engineering. But the question is: why do that for an extinct arch? Only 32-bits, but ColdFire attempted to revive the ISA and that didn't work out, either.
      - mrlonglong 5y ago
        I think we would apply the lessons learned since the 90s and see where that gets us.

deleted 5y ago

[deleted]

jerrysievert 5y ago

I really miss my copy of the m68k programmers reference manual. when I finally had to learn x86, I remember being so frustrated at how fractured it was compared to the beauty that was m68k at the time.

mshockwave 5y ago
I think you're talking about this one? https://m680x0.github.io/doc/official-docs https://m680x0.github.io/doc/official-docs
- jerrysievert 5y ago
  I was actually talking about this one (sorry about the amazon link): https://www.amazon.com/M68000-16-bit-microprocessor-Programmers-reference/dp/013566795X https://www.amazon.com/M68000-16-bit-microprocessor-Programm... much more blue cover - I think I kept it until about 10 years ago, when I did a purge of physical books that didn't have a fairly deep sentimental attachment. of course, that still ended up with hundreds of pounds of paper.