By: Brett (ggtgp.delete@this.yahoo.com), August 12, 2022 4:32 am
Room: Moderated Discussions
Megol (golem960.delete@this.gmail.com) on August 12, 2022 3:04 am wrote:
> Brett (ggtgp.delete@this.yahoo.com) on August 11, 2022 3:26 pm wrote:
> > Any 68k manual, each instruction spells out the bits:
> > https://web.njit.edu/~rosensta/classes/architecture/252software/code.pdf
> >
> > There is unused state in the mode bits that can be used to add another 8 data registers transparently for
> > one source.
> FOR A SMALL SUBSET OF OPERATIONS!
> That's the thing - it's not something that's really available as an extension, it's a very lopsided hack.
Yes, I misread the mode 111 table as having two empty slots, it’s actually three empty slots as the table is only seven high, and burns the register name making it useless.
You would have to replace the useless decrement mode to add another 8 data registers and that would break compatibly.
However you could use one of those three mode 111 slots as a general purpose way to add another 16 bits to almost all instructions. That’s enough added bits to go three operand on 32 registers, and still have 1 bit left over to play with. (5 bits third register, 5 bits to replace burned 111 mode register, 2 bits added to the other register, and 3 bits to add back MODE bits.)
Deciding added instruction length this way is relatively sane, compared to the train wreck that is the random opcodes, until you have to look at the new mode bits. ;)
But x86 is a train wreck also.
> >Though instead the AMMX extension added 32 bit instructions and used a similar format.
> It also wasted the only reasonable opcode space available for a prefix (11 free bits) to add MMX support.
> At least happy they moved from supporting the mostly useless ColdFire sign extension
> opcodes to use the encoding space as a prefix operation as I had been proposing.
> Of course my prefix ideas were more general.
>
> > ColdFire obsoleted the 2 of the 3 opmode operation size bits for all but MOVE loads/stores. That frees up
> > huge opportunities for expansion. The plan may have been to use these bits to double the register file.
> Not relevant as the 68080 is intended to be compatible with Amiga software.
>
> > Ugly, but not so ugly as x86.
> Debatable. X86 is like two separate architectures with some similarities,
> the 8086-80286 was pretty clean, the 80386 too.
>
> Brett (ggtgp.delete@this.yahoo.com) on August 11, 2022 3:26 pm wrote:
> > Any 68k manual, each instruction spells out the bits:
> > https://web.njit.edu/~rosensta/classes/architecture/252software/code.pdf
> >
> > There is unused state in the mode bits that can be used to add another 8 data registers transparently for
> > one source.
> FOR A SMALL SUBSET OF OPERATIONS!
> That's the thing - it's not something that's really available as an extension, it's a very lopsided hack.
Yes, I misread the mode 111 table as having two empty slots, it’s actually three empty slots as the table is only seven high, and burns the register name making it useless.
You would have to replace the useless decrement mode to add another 8 data registers and that would break compatibly.
However you could use one of those three mode 111 slots as a general purpose way to add another 16 bits to almost all instructions. That’s enough added bits to go three operand on 32 registers, and still have 1 bit left over to play with. (5 bits third register, 5 bits to replace burned 111 mode register, 2 bits added to the other register, and 3 bits to add back MODE bits.)
Deciding added instruction length this way is relatively sane, compared to the train wreck that is the random opcodes, until you have to look at the new mode bits. ;)
But x86 is a train wreck also.
> >Though instead the AMMX extension added 32 bit instructions and used a similar format.
> It also wasted the only reasonable opcode space available for a prefix (11 free bits) to add MMX support.
> At least happy they moved from supporting the mostly useless ColdFire sign extension
> opcodes to use the encoding space as a prefix operation as I had been proposing.
> Of course my prefix ideas were more general.
>
> > ColdFire obsoleted the 2 of the 3 opmode operation size bits for all but MOVE loads/stores. That frees up
> > huge opportunities for expansion. The plan may have been to use these bits to double the register file.
> Not relevant as the 68080 is intended to be compatible with Amiga software.
>
> > Ugly, but not so ugly as x86.
> Debatable. X86 is like two separate architectures with some similarities,
> the 8086-80286 was pretty clean, the 80386 too.
>