3 ms·

AmigaDOS (and Kickstart & Workbench) have always been 32 oz variety. Even Motorola 68000 got 32-bit address space and 32-bit register width. Same binary code ru

AmigaDOS (and Kickstart & Workbench) have always been 32 oz variety. Even Motorola 68000 got 32-bit address space and 32-bit register width. Same binary code runs fine on MC68020 and beyond. Internally MC68k was 16-bit, but from a programmer's point of view you got 8x 32-bit data registers, 8x 32-bit address registers (minus stack pointer) and a flat, 32-bit memory space. No 32-bit x 32-bit = 64-bit multiply though, only 16b x 16b = 32b. Same with divide.

Findecanor 4y ago
Oh, there were some badly written programs for 68000 Amigas that didn't run on the 68020 or later. One "clever" trick was to store data in the highest byte of 32-bit pointers — which had worked on the 68000 because it had only a 24-bit address bus. Another thing that didn't work was self-modifying code. The 68020 introduced an instruction cache, which would have had to be cleared first.
- vardump 4y ago
  Yeah, that upper 8-bit address tagging thing was a "clever"... waste of cycles. Just rotating/shifting 32-bit registers by 8 places costs 24 cycles (8 + 2 * n) on 68000, like if the value was passed in a register. Shifting the value by 24 places is even worse, massive 56 cycles... You could also do "move.b (a0), d0" directly from the pointer to pointer address. That'd cost just 8 cycles. Self-modifying code wasn't all that beneficial nor popular on 68k because of ample number of usable registers, 16, including a7, that is used as a stack pointer, but nothing prevented you from using it for something else for a while. I think copy protections and such used weird tricks like SMC. Machine code generators (kind of limited JITs) were useful, but those usually generated large enough blocks of code to flush a small cache by default. There were also some race conditions with DMA (like blitter and perhaps with disk), when DMA completion wasn't properly checked. But 99%+ of code didn't use those tricks and was perfectly compatible.

Findecanor 4y ago

Oh, there were some badly written programs for 68000 Amigas that didn't run on the 68020 or later. One "clever" trick was to store data in the highest byte of 32-bit pointers — which had worked on the 68000 because it had only a 24-bit address bus. Another thing that didn't work was self-modifying code. The 68020 introduced an instruction cache, which would have had to be cleared first.

vardump 4y ago
Yeah, that upper 8-bit address tagging thing was a "clever"... waste of cycles. Just rotating/shifting 32-bit registers by 8 places costs 24 cycles (8 + 2 * n) on 68000, like if the value was passed in a register. Shifting the value by 24 places is even worse, massive 56 cycles... You could also do "move.b (a0), d0" directly from the pointer to pointer address. That'd cost just 8 cycles. Self-modifying code wasn't all that beneficial nor popular on 68k because of ample number of usable registers, 16, including a7, that is used as a stack pointer, but nothing prevented you from using it for something else for a while. I think copy protections and such used weird tricks like SMC. Machine code generators (kind of limited JITs) were useful, but those usually generated large enough blocks of code to flush a small cache by default. There were also some race conditions with DMA (like blitter and perhaps with disk), when DMA completion wasn't properly checked. But 99%+ of code didn't use those tricks and was perfectly compatible.