By: rwessel (robertwessel.delete@this.yahoo.com), November 28, 2014 1:52 am

Room: Moderated Discussions

Peter Lund (peterfirefly.delete@this.gmail.com) on November 27, 2014 1:10 pm wrote:

> rwessel (robertwessel.delete@this.yahoo.com) on November 24, 2014 11:48 pm wrote:

> >

> > It is astonishing, at least in hindsight, just how badly Motorola screwed up the 68K ISA with

> > the '020. While the groundwork for that had been laid in the original 68K (the unused bits used

> > in the '020 for the additional addressing modes were in the extension words), the 68000 and '010

> > had all instructions lengths determined in the first (16-bit) word of the instruction.

>

> Even that was pretty bad. I did the experiment of trying to find a small PLA that would give me the

> length + a valid bit for each of the 2^16 values for the first word. The size was not small...

>

> Of course I could have broken the problem down into several smaller PLAs +

> a big, final one. Maybe it would have been reduced to reasonable size.

Still, a far simpler task than trying to do the same for x86.

And certainly a multi-PLA scheme would have been much more reasonable. Just as a first order approximation, unless the first four bits are 0001-0011 or 0110, you at worst need 10 bits to decode for the base instruction (and determine its size), and then (possibly, based on those ten bits), a single six bit mode/reg field to determine the extension. And there are definite usable patterns in those ten bits. The other cases are the storage-to-storage move instruction (which are all identical, and just have two mode/reg fields), and the conditional branch instructions (which just need the last eight bits inspected to determine if there's an extension word).

> The '020 was just insane. Why add more stupid addressing modes that nobody uses!? I thought

> the 68K was supposed to be based on real data from Len Shustak's PhD thesis on the PDP-11?

>

> > VAX, of course, made the mistake from the very start, using basically the

> > same approach to embed decode bits in the variably placed extensions.

>

> But each part is (thankfully) easier to decode.

OTOH, you can have a lot more of them on VAX - 68K limited it to two.

> rwessel (robertwessel.delete@this.yahoo.com) on November 24, 2014 11:48 pm wrote:

> >

> > It is astonishing, at least in hindsight, just how badly Motorola screwed up the 68K ISA with

> > the '020. While the groundwork for that had been laid in the original 68K (the unused bits used

> > in the '020 for the additional addressing modes were in the extension words), the 68000 and '010

> > had all instructions lengths determined in the first (16-bit) word of the instruction.

>

> Even that was pretty bad. I did the experiment of trying to find a small PLA that would give me the

> length + a valid bit for each of the 2^16 values for the first word. The size was not small...

>

> Of course I could have broken the problem down into several smaller PLAs +

> a big, final one. Maybe it would have been reduced to reasonable size.

Still, a far simpler task than trying to do the same for x86.

And certainly a multi-PLA scheme would have been much more reasonable. Just as a first order approximation, unless the first four bits are 0001-0011 or 0110, you at worst need 10 bits to decode for the base instruction (and determine its size), and then (possibly, based on those ten bits), a single six bit mode/reg field to determine the extension. And there are definite usable patterns in those ten bits. The other cases are the storage-to-storage move instruction (which are all identical, and just have two mode/reg fields), and the conditional branch instructions (which just need the last eight bits inspected to determine if there's an extension word).

> The '020 was just insane. Why add more stupid addressing modes that nobody uses!? I thought

> the 68K was supposed to be based on real data from Len Shustak's PhD thesis on the PDP-11?

>

> > VAX, of course, made the mistake from the very start, using basically the

> > same approach to embed decode bits in the variably placed extensions.

>

> But each part is (thankfully) easier to decode.

OTOH, you can have a lot more of them on VAX - 68K limited it to two.