On Sunday, July 9, 2023 at 8:21:35 PM UTC-5, BGB wrote:
> On 7/9/2023 6:44 PM, MitchAlsup wrote:
> > On Sunday, July 9, 2023 at 5:57:47 PM UTC-5, BGB wrote:
> >> On 7/9/2023 3:38 PM, MitchAlsup wrote:
> >>> On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
> >>>> On 7/9/2023 10:34 AM, Anton Ertl wrote:
> >>>>> Quadibloc <jsa...@ecn.ab.ca> writes:
> >>>>>> The Motorola 68000 divided the 16 registers it did provide into two
> >>>>>> groups; the general registers and the address registers. So it needed
> >>>>>> three-bit fields to specify a register in either group.
> >>>>>>
> >>>>>> The Motorola 68000 was a CISC processor; it didn't "need" more than
> >>>>>> eight registers in a register bank.
> >>>>>
> >>>>> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
> >>>>> general-purpose registers.
> >>>>>
> >>>>> I think that the 16-bit memory interface of the 68000 meant that they
> >>>>> wanted to have many instructions that fit in 16 bits, and with more
> >>>>> than 8 registers this becomes difficult (see also the PDP-11). The
> >>>>> 8086 is an example that trying to fit useful instructions in 8 bits
> >>>>> leads to even more limitations.
> >>>>>
> >>>>> Another example is the RISC-V C extension (16-bit wide instructions),
> >>>>> where a number of these instructions can access only 8 of the 32
> >>>>> registers of the architecture.
> >>>>>
> >>>> FWIW:
> >>>> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
> >>>> encodings.
> >>>>
> >>>> However, in both ISA's, they are effectively Load/Store with typically
> >>>> only 2R encodings for the 16-bit ops.
> >>>>
> >>>> In my case, there are some 16-bit ops with access to R16..R31, but
> >>>> mostly limited to special cases:
> >>>> MOV, ADD
> >>>> MOV.{L/Q} (SP, Disp4), Rn
> >>>> ...
> >>>> Nothing in 16-bit land has access to R32..R63 though.
> >>>>
> >>>>
> >>>> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
> >>>> space. But, arguably this doesn't seem terribly worthwhile as the "hit
> >>>> rate" for being limited to 8 registers is lower than that for being
> >>>> limited to, say: "Rn=Rn+Rm;" and similar.
> >>>>
> >>>> Comparably, both RV-C and Thumb had a lot of hair in terms of their
> >>>> 16-bit encodings as well.
> >>>>
> >>>>
> >>>>
> >>>> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
> >>>> operations, but paid for this by having an absurdly small opcode space
> >>>> (with a lot of instructions being encoded by playing trickery with the
> >>>> register fields and addressing modes).
> >>>>>> Providing 32 registers is something
> >>>>>> RISC processors do - for them, it's worth the opcode space, because
> >>>>>> opcode space is saved elsewhere
> >>>>>
> >>>>> No, it's because they have the opcode space. All those with 32
> >>>>> registers have 32-bit memory interfaces and therefore could afford
> >>>>> 32-bit instructions, so they could afford encoding registers in 5
> >>>>> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
> >>>>> instructions, but only 16 GPRs (maybe due to area concerns, maybe
> >>>>> because the 801 only has 16 registers), and used the extra bits for
> >>>>> stuff like shifts or conditions.
> >>>>>
> >>>> In my case, I have some encodings (and an operating mode) which have
> >>>> 6-bit register fields, conditional execution, etc.
> >>>>
> >>>> But, compared with most RISC's (with a 32-bit instruction size), mine
> >>>> has comparably small immediate fields.
> >>>>
> >>>> Though, interestingly, XG2 Mode has typically the same sized immediate
> >>>> fields as SH-5 (which also had 6-bit register fields).
> >>>>
> >>>> Baseline mode only has 5-bit register fields for the most part, whereas
> >>>> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
> >>>>
> >>>>
> >>>>
> >>>> I don't see the smaller immediate fields as too big of a loss though:
> >>>> There is a reasonably good hit-rate with the current immediate fields;
> >>>> The ISA design does not overly penalize cases where an immediate can't
> >>>> fit in the immediate-field;
> >>>> There are also Jumbo prefixes.
> >>>>
> >>>> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
> >>>> typically looking at a 3 instruction fallback case.
> >>> <
> >>> I think they (THEY) would argue mostly 1 becomes 2 instructions.
> >>> Almost all displacements greater than 12-bits become a 2 instruction
> >>> sequence; THEY would argue that this is where most big immediates
> >>> come from.
> >>> <
> >> Well, say, you have:
> >> XORI X10, X11, 511 //OK, fine.
> >> Vs:
> >> XORI X10, X11, 65521 //Now what?
> >>
> >> You get, maybe:
> >> LUI X5, 16
> >> ADDI X5, X5, -15
> >> XOR X10, X11, X5
> >>
> >> This is kinda weak...
> >>
> > I agree with you that it is weak.
> >>
> >> Meanwhile, in BJX2 (without jumbo), you can fake, say:
> >> ADD R4, 16777213, R7
> >> As a 2-op sequence:
> >> LDIZ 16777213, R0
> >> ADD R4, R0, R7
> > <
> > Even::
> > <
> > ADD Rd,Rs,#0x123456789abcdef
> > <
> > Is 1 (One, single) instruction. It occupies 3 words, but it is 1 instruction.
> > <
> > So is::
> > <
> > STD #0x123456789abcdef,[Rd,Rs<<3,#0x123456789abcdef]
> > <
> > 1 instruction, this time it occupies 5 words, but it remains 1 instruction.
> > RISC-V code for this is atrocious.
> Yeah...
> BJX2 can't do this either.
>
> With jumbo encodings, one can at least do:
> ADD R4, 0x12345678, R7
> As a single 64-bit instruction.
>
> Could in theory do:
> ADD R4, 0x123456789abcde, R7
>
> As a 96-bit encoding, if it were common enough to justify the LUT cost
> of enabling it. Granted, these exist implicitly if one enables the SIMD
> vector immediate values, since the SIMD immediate values need the same
> mechanism.
>
>
>
> Still no 64-bit displacements, mostly for timing reasons.
>
> Despite there being a 96-bit mode, only the low 48 bits are subject to
> address calculation, and only with a 33 bit displacement.
>
> The compiler can mostly gloss over this though, seeing if a person uses
> 'long' as an array index.
>
> Though, annoyingly, this does mean that it needs to end up falling back
> to a slower case if one uses 'size_t' or 'ssize_t' rather than 'int' for
> their array index.
> >>
> >> Which is part of why I burnt such a big chunk of encoding space on a
> >> "Load Imm24 into R0" instruction; 2 actually:
> >> LDIZ Imm24u, R0 //Zero-Extend
> >> LDIN Imm24n, R0 //One-Extend
> >> Which can be seen as a virtual:
> >> MOV Imm25s, R0
> >>
> > You are still wasting instructions pasting bits together that can be "had"
> > and a constant. This consumes pipeline cycles, registers, forwarding
> > energy,... There is no cheaper way to deliver an operand into calculation
> > than as a constant.
> As noted, this is excluding "jumbo", which eliminates most of the
> multi-op bit-pasting, but isn't regarded as part of the core ISA in the
> smaller profiles (and didn't exist in early forms of the ISA design).
>
>
> Then again, one option could be to promote the jumbo prefixes to the
> core ISA, in a similar way to what happened with predicated instructions.
>
> Early on, I realized that the underlying logic for predicated
> instructions was still needed for conditional branches, so there wasn't
> any good reason *not* to promote it to core.
> >>
> >> But, it sort of paid off as this instruction left encoding space that
> >> could also be used for things like Jumbo Prefixes and PrWEX encodings,
> >> which in some of my other design attempts I had attempted
> >> (unsuccessfully) to conjoin them with the Branch instructions (where
> >> trying to WEX a branch instruction is also invalid in my designs).
> >>
> > Yes, go ahead and pat yourself on the back for something I consider
> > to be poor.
> Well:
> MOV Imm25s, R0
> Is sort of a sledgehammer solution, but like, it is workable in the
> majority of cases...
<
MOV Rd,#123456789abcdef
<
works in all cases..........
>
> The
> FEii-iiii-FAii-iiii MOV Imm48u, R0
> FEii-iiii-FBii-iiii MOV Imm48n, R0
> Encoding being, arguably, even more of a sledgehammer...
>
>
> Jumbo and PrWEX are also a serious break in orthogonality, but, they
> also work.
>
> PrWEX covers the F0 and F2 blocks, which are basically where most of the
> most-used instructions are located. The F1 block can't generally be
> WEX'ed, so this isn't an issue.
>
>
> The F8 block is an annoyance, would have been nice to be able to encode
> things like, say:
> ADD?T 0x1234, R5 | MOV.Q (R4, 0x123), R6
>
> But, alas...
>
>
> But, without some of this, couldn't have shoved in the 64-bit "BRA
> Abs48" encoding...
> FFii-iiii-FAii-iiii BRA Abs48
> FFii-iiii-FBii-iiii BSR Abs48
>
>
> No way at present to encode conditional Abs48 branches though (since
> this part of the encoding space overlaps with PrWEX).
<
I use the equivalent of::
<
LDA IP,[any AGEN you want]
<
> One could have to make a case that conditional Abs48 is more valuable
> than Jumbo+PrWEX...
>
> At present though, there is no need for conditional Abs48 branches
> (since their main use-case is things like DLL imports and lambda-stubs
> and similar, which don't need to be able to be conditional).
> >>
> >> There are also a relatively limited number of combinations where A+B~=32
> >> and A+A+C=64, ...
> >>
> >> But, 24+9=33 works well as 33 bits can represent both the entire signed
> >> 32-bit range and the entire 32-bit unsigned range, thus covering all
> >> 32-bit constants. Likewise, 24+24+16=64, so this is also good.
> >>
> >>
> >> But, I had only ended up going with 20 bits for branches, as +/- 1MB has
> >> thus far been "mostly" sufficient.
> > <
> > Not surprising.
> Yeah.
>
> Most of what I am running fits in this limit.
>
>
> With some combinations of features, have pushed ROTT over the 1MB size
> limit...
<
Why have a limit ?? My GOT can be 62-bits in size leaving code and data another
62-bits without encroaching on OS space.
>
> Still nowhere near the +/- 32MB size limit though for the 2-part ops.
>
> Could make a case though that maybe the Disp33s encodings should be used
> here. But, the Disp25s case existed first...
> >>
> >> For a branch within the same EXE/DLL, most likely sufficient. For a
> >> branch outside the current DLL; one isn't going to be using a normal
> >> PC-relative branch in the first place.
> >>
> > I call from one DLL to another in a single instruction (which loads IP from
> > GOT[function#].) The linker can change this back to LDA ip,[GOT[function#]]
> > when an extern function() becomes a local function (and avoid changing
> > code size--and thus label values).
> The current mechanism I have is that, in the "Import Address Table", if
> the import has the form:
> FF00-0000-FA00-0000
> Then the loader patches it up as an Abs48 branch (but, the
> compiler/linker can provide an extra 8 bytes for in-case the PE loader
> wants to patch it up to an Inter-ISA jump).
>
> Else, it is patched up as a raw import address (in which case a multi-op
> sequence needs to load the address from memory and then branch to it).
> >>
> >>
> >>
> >> Granted, one could argue that RISC-V has a "slight" advantage for
> >> long-distance branches as they can (indirectly) perform a branch like:
> >> AUIPC X5, DispHi20
> >> JALR X1, X5, DispLo12
> > <
> > CALA [DISP32] // 32-bit address
> > CALA [DISP64] // 64-bit address
> > <
> > CALX [GOT32[function#]] // 32-bit GOT 64-bit address
> > CALX [GOT64[function#]] // 64-bit GOT 64-bit address
> > <
> > And none of these require wasting a register.
> OK.
>
> Closest I have is the Abs48 branches, but this still isn't part of the
> core ISA.
> >>
> >> Without needing a jumbo prefix or other similar mechanism.
> >>
> >>
> >> Exceeding the Load/Store displacements is still a bit of an issue though
> >> with RISC-V; as there is not really a "good" fallback that I can think
> >> of at the moment.
> >>>>
> >>>> But, OTOH, my ISA has both:
> >>>> ADD Rm, Imm9u, Rn
> >>>> And:
> >>>> ADD Imm16s, Rn
> >>>>
> >>>> Whereas RISC-V only has:
> >>>> ADD Rd, Rs, Imm12s
> >>> <
> >>> Whereas My 66000 has:
> >>> ADD Rd,Rs,#Imm16
> >>> ADD Rd,+Rs1,+Rs2
> >>> ADD Rd,+Rs1,-Rs2
> >>> ADD Rd,-Rs1,+Rs2
> >>> ADD Rd,-Rs1,-Rs2
> >>> ADD Rd,+Rs,#Imm32
> >>> ADD Rd,-Rs,#Imm32
> >>> ADD Rd,+Rs,#Imm64
> >>> ADD Rd,-Rs,#Imm64
> >>> ADD Rd,Rs,+#imm5
> >>> ADD Rd,Rs,-#Imm5
> >>> ADD Rd,+#imm5,Rs
> >>> ADD Rd,-#imm5,Rs
> >>> ADD Rd,#Imm32,+Rs
> >>> ADD Rd,#Imm32,-Rs
> >>> ADD Rd,#Imm64,+Rs
> >>> ADD Rd,#Imm64,-Rs
> >>>>
> >>>> Partly because some tasks (like adjusting the stack pointer) don't map
> >>>> over well to a 9-bit immediate field.
> >>> <
> >>> I have 16-bits........
> >> I have:
> >> ADD Imm16s, Rn
> > <
> > You also write operands and results in the wrong direction....................
<
> My ASM notation evolved out of the SH ASM notation as used by GAS and
> similar.
<
But you do have the ability to fix it, do you not ??
>
> Could have been worse:
> ADD #0x1234, %R4
> MOV.L %R4, @R5
>
> But, like, I didn't bother with '#' and '%' and similar as they were
> basically frivolous, and I ended up preferring (R5) over @R5, ...
> Dropping these did not lead to any ambiguity in terms of parsing.
<
I agree with you that %r is ugly for a register name.
I dislike @r because it is sufficiently unlike @ in C.
>
>
> But, yeah, partly the argument ordering stuck around as a remnant from
> its distant origins in the GAS notation...
>
>
> Basically, it is in a similar category to if one writes their x86 ASM like:
> addl 16(%ecx),%edx
> orl $64,%edx
>
> Clearly, some people think this is a valid style...
<
Claiming x86 is the nicest to read ISA ever ???

On 7/9/2023 3:41 PM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>
>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>
>> I guess a question is if it had been used in the PC instead of x86, if
>> Motorola could have then made it performance competitive with what later
>> x86 systems became?...
>
> Hard to say. At that point Intel just executed better than Moto.
>

Could be.
Either that, or there was some architectural factor at play.

>> OTOH, the instruction encoding does seem at least cleaner than x86...
>
> No S* Sherlock. And the huge win of flat rather than segmented addressing.
>

That hardware x86 decoders work at all is kind of impressive in a way...

>> I guess another mystery could have been if a 32-bit RISC design could
>> have been made more viable with an 8 or 16 bit memory bus?...
>>
>> From what I can gather, processors from that era didn't really use L1
>> or L2 caches though. This wouldn't likely bode well.
>
> Cache? What's a cache? The PC was shipped in 1981 and the first
> general purpose CPU chips I know with a cache were the 68030 in 1987
> and i486 in 1989.

OK.

As can be noted, my familiarity with computers from that era is a bit
sketchy at times...

On Sunday, July 9, 2023 at 10:51:48 PM UTC-4, BGB wrote:
> On 7/9/2023 3:41 PM, John Levine wrote:
> > According to BGB <cr8...@gmail.com>:
> >>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
> >>>
> >>> Legend says that if Moto had been able to ship the 68008 in quantity,
> >>> IBM would have used it in the IBM PC rather than the 8088. If only.
> >>
> >> I guess a question is if it had been used in the PC instead of x86, if
> >> Motorola could have then made it performance competitive with what later
> >> x86 systems became?...
> >
> > Hard to say. At that point Intel just executed better than Moto.
> >
> Could be.
> Either that, or there was some architectural factor at play.
> >> OTOH, the instruction encoding does seem at least cleaner than x86...
> >
> > No S* Sherlock. And the huge win of flat rather than segmented addressing.
> >
> That hardware x86 decoders work at all is kind of impressive in a way...
> >> I guess another mystery could have been if a 32-bit RISC design could
> >> have been made more viable with an 8 or 16 bit memory bus?...
> >>
> >> From what I can gather, processors from that era didn't really use L1
> >> or L2 caches though. This wouldn't likely bode well.
> >
> > Cache? What's a cache? The PC was shipped in 1981 and the first
> > general purpose CPU chips I know with a cache were the 68030 in 1987
> > and i486 in 1989.

68020 had a 256B i-cache. Do buffers count as caches? I think the 68000 or
68010 had a three word buffer it could execute out of.

> OK.
>
> As can be noted, my familiarity with computers from that era is a bit
> sketchy at times...

On 7/9/2023 3:49 PM, MitchAlsup wrote:
> On Sunday, July 9, 2023 at 3:20:57 PM UTC-5, BGB wrote:
>> On 7/9/2023 2:55 PM, John Levine wrote:
>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>> One should also not forget bus width, which also costs money.
>>>> The ARM2 was able to beat the 68000 on speed by a large factor
>>>> with a lower transistor count, but it also had a 32-bit data bus
>>>> (which, considering periphery, might have been too expensive when
>>>> the 68000 was designed).
>>>
>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>
>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>
>> I guess a question is if it had been used in the PC instead of x86, if
>> Motorola could have then made it performance competitive with what later
>> x86 systems became?...
> <
> If 68K was used instead of 8086, PC would have been more like LISA.
> {{which evolved into MacIntosh.}

I guess there was:
LISA / Macintosh;
Apple IIgs (WDC 65C816 based).

And, I guess they decided to go with the M68K rather than the 65C816 for
the Macintosh...

Though, reading some stuff, seems the Macintosh predated the IIgs as well...

I guess elsewhere, the 65C816 vs M68K battle played out in the SNES vs
Sega Genesis (though, Genesis was generally more powerful and had more
RAM than the SNES in this case, ...).

>>
>> Like, seemingly, relative to clock-speed, the M68K was giving comparably
>> weak performance compared with many other architectures (and AFAIK part
>> of why Apple had jumped from M68K to PPC?).
> <
> 68K was out performing 8086 in that era
> After 486 it was all done.

Probably. Had interacted some with some M68K Macs back in the 90s, they
were painfully slow compared with PCs of the time.

I guess the mystery is if in an alternate timeline, M68K could have seen
similar speed gains to what x86 saw, or if there was a property that
would have turned into a performance limiter (such as M68K having more
complicated addressing modes).

Or, if it was more that Intel effectively "pulled a rabbit out of a hat"
regarding x86?...

>>
>> OTOH, the instruction encoding does seem at least cleaner than x86...
>>
> Well, Mrs. Lincoln, how did you like the play ??

Hmm...

>>
>>
>> I guess another mystery could have been if a 32-bit RISC design could
>> have been made more viable with an 8 or 16 bit memory bus?...
>>
>> From what I can gather, processors from that era didn't really use L1
>> or L2 caches though. This wouldn't likely bode well.
> <
> There was an entire paradigm shift at the CISC->RISC boundary.

Yeah.

I don't know about the design sensibilities of older CPUs.
But, I do suspect that making something "fast" without an L1 cache or
similar is likely to be a bit of an issue...

I am having enough challenges even with a cache.

Then again, even as slow as my core is, it is looking like it is looking
like it is probably a good order of magnitude faster than some of the
early (80s era) PCs.

Getting some stats (by adding some stat outputs to my Verilator simulation):
~ 0.6 to 0.8 bundles/clock
Lower during RAM or MMIO intensive tasks
~ 1.1 to 1.8 instructions/bundle
~ 1.0 during initial Boot
(ROM is built size-optimized, which does not use the WEXifier)
Seems to vary dynamically depending on the task.
~ 30-50 MIPs
~ 35-40 MIPs while booting Doom
~ 40-50 MIPs while running Doom

Normal code is running nowhere near the "hard" limits mostly due to
things like cache miss penalties and similar. Things also seem to be
pretty variable.

I have made some fixes that seem to have got my CPU core closer in speed
to what was predicted by my emulator (but, still working on fixing some
more issues). Most of the issues have been in "outer ring" stuff, the
organization of the ringbus and issues with the RAM-backed VRAM module, ...

Elsewhere, I have noted that it seems to be ~ 1.2 BJX2 MIPs per
Dhrystone MIPs (where, say, ~ 79000 seems to map to my core running ~ 54
million instructions/second).

In a very rough estimate, it appears to correlate to Doom fps:
~ 20 MIPs -> 10 fps
~ 30 MIPs -> 15 fps
~ 40 MIPs -> 20 fps
~ 50 MIPs -> 30 fps

Though, if similar holds for early PCs, it implies that something like a
386SX-25 or similar would have been incapable of giving a solid 30 fps
or similar in Doom.

But, as can be noted, I mostly started out in a world where pretty much
any PC around could play Doom and similar without much issue.

But, yeah, it is seeming like maybe early PCs were more limited than I
was aware.

....

On 7/9/2023 1:41 PM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>
>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>
>> I guess a question is if it had been used in the PC instead of x86, if
>> Motorola could have then made it performance competitive with what later
>> x86 systems became?...
>
> Hard to say. At that point Intel just executed better than Moto.

Also, due to the success of the PC, Intel had lots of money to invest in
new development, including better performance.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/10/2023 12:43 AM, Stephen Fuld wrote:
> On 7/9/2023 1:41 PM, John Levine wrote:
>> According to BGB  <cr88192@gmail.com>:
>>>> The original 68000 came in 16 and 8 bit bus versions, just like the
>>>> 8086 and 8088.
>>>>
>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>
>>> I guess a question is if it had been used in the PC instead of x86, if
>>> Motorola could have then made it performance competitive with what later
>>> x86 systems became?...
>>
>> Hard to say.  At that point Intel just executed better than Moto.
>
> Also, due to the success of the PC, Intel had lots of money to invest in
> new development, including better performance.
>

Yeah. The question is, had that pile of cash gone to Moto instead, could
they have developed the fast CPUs instead of Intel?...

Would the world have all later collectively gone to PowerPC, or might
instead PowerPC have never happened?...

....

>

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, July 9, 2023 at 3:20:57=E2=80=AFPM UTC-5, BGB wrote:
>If 68K was used instead of 8086, PC would have been more like LISA.
>{{which evolved into MacIntosh.}

Lisa did not evolve into MacIntosh. Lisa and Annie (MacIntosh) were
separate projects inside Apple (there was also Sara (Apple III) and
Diana (Apple IIe)), with originally different goals. Of course, once
Jobs was ousted from the Lisa team and put himself into the MacIntosh
team, the goals of that project shifted, and the design, too. It's
more accurate to say that the MacIntosh morphed to be more like the
Lisa. Without Jobs the MacIntosh would have been more in the
direction of the Canon Cat.

I very much doubt that the IBM PC would have been more like the Lisa
if it had a 68k. The goals of the designers of the IBM PC were
completely different than the goals of the designers of Lisa. My
guess is that we would have seen a machine with MS-DOS or CP/M-68K, or
something like it, with expansion slots, etc., much like the actual
IBM PC. It would have been easier to write software for it (no
segments for going beyon 64k), and it would have had an easier time
with later models (with support for more than 640KB RAM), but other
than that it would not have been much different.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

BGB <cr88192@gmail.com> schrieb:
> On 7/10/2023 12:43 AM, Stephen Fuld wrote:
>> On 7/9/2023 1:41 PM, John Levine wrote:
>>> According to BGB  <cr88192@gmail.com>:
>>>>> The original 68000 came in 16 and 8 bit bus versions, just like the
>>>>> 8086 and 8088.
>>>>>
>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>>
>>>> I guess a question is if it had been used in the PC instead of x86, if
>>>> Motorola could have then made it performance competitive with what later
>>>> x86 systems became?...
>>>
>>> Hard to say.  At that point Intel just executed better than Moto.
>>
>> Also, due to the success of the PC, Intel had lots of money to invest in
>> new development, including better performance.
>>
>
> Yeah. The question is, had that pile of cash gone to Moto instead, could
> they have developed the fast CPUs instead of Intel?...

ARM showed you could have much higher performance than either
Motorola or Intel, with a much simpler design and far lower
transistor count and power requirements. It's hard to find hard
numbers, but it appears the ARM2 was roughly on par with the 68020
as far as performance was concerned, at half the clock speed.

So, it _was_ possible at that time to develop something faster with a
very low budget.

Obtaining significantly higher performance would require much more
resources, something that ARM didn't invest in for a long time,
focusing on low-power applications instead.

In article <u8g5p3$2f2h7$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> I guess there was:
> LISA / Macintosh;
> Apple IIgs (WDC 65C816 based).
>
> And, I guess they decided to go with the M68K rather than the
> 65C816 for the Macintosh...

A sound decision. The 65C816 memory model makes 8086 look flexible and
easy to program. 65C816 sacrificed far too much to make it possible to
run 6502 code.

John

BGB <cr88192@gmail.com> writes:
>On 7/10/2023 12:43 AM, Stephen Fuld wrote:
>> Also, due to the success of the PC, Intel had lots of money to invest in
>> new development, including better performance.
>>
>
>Yeah. The question is, had that pile of cash gone to Moto instead, could
>they have developed the fast CPUs instead of Intel?...

Motorola had significant cash from selling the 68k to the workstation
(Apollo, HP, Sun) and home computer (Amiga/Commodore, Atari, Sinclair)
manufacturers, and Apple (MacIntosh).

Their big problem was that the workstation market was more
performance-conscious than and not as architecture-locked as the PC
market, so they switched to RISCs when they gave more performance.
And they were late to the market with their own RISC (88100, released
in April 1988), so almost everybody had already switched to their own
RISC: HP to HPPA (1986), Sun to SPARC (Sun 4 in 1987); Apollo also
developed their own CPU (PRISM), but was late (first release 1988);
Apollo had various difficulties by that time, and HP bought them in
1989. The home computers died, and Apple decided to switch to RISC
(initially 88k, later PowerPC).

And while the 68020 was earlier than the 80386 (which was in many
respects comparable), the 68040 and 68060 were later than their Intel
counterparts, and not clock-rate competetive.

>Would the world have all later collectively gone to PowerPC, or might
>instead PowerPC have never happened?...

Maybe AIM would not have happened, and Power would have stayed an
IBM-only thing. Motorola would have likely still had their own RISC,
although it's not clear how that would have fared (Intel had both the
i960 and the i860, and while they initially thought that the i960
would be the future, they seemed to hardly market it after the IBM PC
market took off (if you read the story of the 386, they started out as
a minor project (which the i960 being the big project at the time),
and at some point they became kings).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

BGB <cr88192@gmail.com> writes:
>On 7/9/2023 3:49 PM, MitchAlsup wrote:
>I guess there was:
> LISA / Macintosh;
> Apple IIgs (WDC 65C816 based).
>
>And, I guess they decided to go with the M68K rather than the 65C816 for
>the Macintosh...

The MacIntosh was originally planned with a 6809. The 65C816 was far
too late for the MacIntosh.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

BGB <cr88192@gmail.com> writes:
>I guess another mystery could have been if a 32-bit RISC design could
>have been made more viable with an 8 or 16 bit memory bus?...

I think they would have been designed significantly differently; maybe
like ARM T32 (Thumb) or like RV32IC, or maybe with more focus on small
code size.

Note also that assembly-language programming was much more important
for 8-bit and 16-bit microprocessors than for RISCs, and human
programmers are better at making use of quirky instruction sets than
compilers, so, e.g., the 8086s instructions with implicit registers
may have been more advantageous at the time than one might think after
comparing, say the IA-32 and ARM T32 code sizes for compiled code
(from, e.g.,<2022Oct17.112448@mips.complang.tuwien.ac.at>)

> From what I can gather, processors from that era didn't really use L1
>or L2 caches though. This wouldn't likely bode well.

Definitely not the microprocessors of the 8-bit and 16-bit era.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

John Levine wrote:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>> One should also not forget bus width, which also costs money.
>> The ARM2 was able to beat the 68000 on speed by a large factor
>> with a lower transistor count, but it also had a 32-bit data bus
>> (which, considering periphery, might have been too expensive when
>> the 68000 was designed).
>
> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>
> Legend says that if Moto had been able to ship the 68008 in quantity,
> IBM would have used it in the IBM PC rather than the 8088. If only.

IBM wanted an intentionally crippled/low-performance system that would
not compete in any way with their small/medium systems?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>
>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>
>> I guess a question is if it had been used in the PC instead of x86, if
>> Motorola could have then made it performance competitive with what later
>> x86 systems became?...
>
> Hard to say. At that point Intel just executed better than Moto.
>
>> OTOH, the instruction encoding does seem at least cleaner than x86...
>
> No S* Sherlock. And the huge win of flat rather than segmented addressing.
>
>> I guess another mystery could have been if a 32-bit RISC design could
>> have been made more viable with an 8 or 16 bit memory bus?...
>>
>> From what I can gather, processors from that era didn't really use L1
>> or L2 caches though. This wouldn't likely bode well.
>
> Cache? What's a cache? The PC was shipped in 1981 and the first
> general purpose CPU chips I know with a cache were the 68030 in 1987
> and i486 in 1989.

That 486 had a combined code/data cache of just 8 KB, and that was still
enough to make a huge difference: I had written a near-perfect
Game-of-Life competition entry: If the target had been the 386 I might
have won, but with the 486 David Stafford came up with an algorithm
which could fit most of the problem space inside those 8 KB. I the end
his entry ended up twice as fast as my code.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

robf...@gmail.com wrote:
> On Sunday, July 9, 2023 at 10:51:48 PM UTC-4, BGB wrote:
>> On 7/9/2023 3:41 PM, John Levine wrote:
>>> According to BGB <cr8...@gmail.com>:
>>>>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>>>>
>>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>>
>>>> I guess a question is if it had been used in the PC instead of x86, if
>>>> Motorola could have then made it performance competitive with what later
>>>> x86 systems became?...
>>>
>>> Hard to say. At that point Intel just executed better than Moto.
>>>
>> Could be.
>> Either that, or there was some architectural factor at play.
>>>> OTOH, the instruction encoding does seem at least cleaner than x86...
>>>
>>> No S* Sherlock. And the huge win of flat rather than segmented addressing.
>>>
>> That hardware x86 decoders work at all is kind of impressive in a way...
>>>> I guess another mystery could have been if a 32-bit RISC design could
>>>> have been made more viable with an 8 or 16 bit memory bus?...
>>>>
>>>> From what I can gather, processors from that era didn't really use L1
>>>> or L2 caches though. This wouldn't likely bode well.
>>>
>>> Cache? What's a cache? The PC was shipped in 1981 and the first
>>> general purpose CPU chips I know with a cache were the 68030 in 1987
>>> and i486 in 1989.
>
> 68020 had a 256B i-cache. Do buffers count as caches? I think the 68000 or
> 68010 had a three word buffer it could execute out of.

The x86 all had instruction prefetch buffers, if you managed to
overwrite code that had already been prefetched, the cpu would ignore it!

6/8/16?/32 bytes for 8088/8086/286/386, we used it to determine exactly
which CPU model we were executing on, since we didn't have CPUID.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>John Levine wrote:
>> Legend says that if Moto had been able to ship the 68008 in quantity,
>> IBM would have used it in the IBM PC rather than the 8088. If only.
>
>IBM wanted an intentionally crippled/low-performance system that would
>not compete in any way with their small/medium systems?

Not a problem with the 68008. Cf. Sinclair QL.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> John Levine wrote:
>> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> One should also not forget bus width, which also costs money.
>>> The ARM2 was able to beat the 68000 on speed by a large factor
>>> with a lower transistor count, but it also had a 32-bit data bus
>>> (which, considering periphery, might have been too expensive when
>>> the 68000 was designed).
>>
>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>
>> Legend says that if Moto had been able to ship the 68008 in quantity,
>> IBM would have used it in the IBM PC rather than the 8088. If only.
>
> IBM wanted an intentionally crippled/low-performance system that would
> not compete in any way with their small/medium systems?

Almost any statement that $COPMANY wants something is an
overgeneralization. Large companies are made up of very different
people in very different departnments, all following different
departmental or personal goals which (hopefully) contribute
something positive to the bottom line of $COMPANY.

I once read that somebody at IBM was irked at Apple's success and
wanted something that could be produced cheaply and that could
oust the Apple II from the low-end commercial market, where IBM
wasn't selling anything anyway.

It did not need to be high-performance for running a spreadsheet.
From "fast, cheap, good, pick any two" they chose fast and cheap (to
produce), but the PC was good enough for its purpose.

They also made it open, because of why not? That would increase
market penetration.

Little did anybody at IBM realize what they would unleash...

According to Thomas Koenig <tkoenig@netcologne.de>:
>I once read that somebody at IBM was irked at Apple's success and
>wanted something that could be produced cheaply and that could
>oust the Apple II from the low-end commercial market, where IBM
>wasn't selling anything anyway.

That's my understanding. It was a skunkworks project in Florida, far
away from the main IBM development centers. They made it mostly out of
vendor parts to speed up development. They intended to use an 8085 or
Z80 until fairly far along someone figured that would be just like all
the other micro boxes only more expensive. It was too late to make the
bus wider, and probably also too expensive, but they were able to swap
out the Z80 for a 16 bit chip.

>Little did anybody at IBM realize what they would unleash...

Indeed. Particularly after the sweetheart deal with tiny obscure
Microsoft that let them sell the same operating system to everyone
else. It's well documented that Bill's mother was on a board with IBM
CEO John Open and talked up her son's company, which he duly passed
along to Boca.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Monday, July 10, 2023 at 12:28:47 PM UTC+3, Terje Mathisen wrote:
> John Levine wrote:
> > According to Thomas Koenig <tko...@netcologne.de>:
> >> One should also not forget bus width, which also costs money.
> >> The ARM2 was able to beat the 68000 on speed by a large factor
> >> with a lower transistor count, but it also had a 32-bit data bus
> >> (which, considering periphery, might have been too expensive when
> >> the 68000 was designed).
> >
> > The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
> >
> > Legend says that if Moto had been able to ship the 68008 in quantity,
> > IBM would have used it in the IBM PC rather than the 8088. If only.
> IBM wanted an intentionally crippled/low-performance system that would
> not compete in any way with their small/medium systems?
>

According to my understanding, when IBM PC project started S/370 models 125
and 135 were already obsolete with annual sails close to zero.
4331 was a flop on its way out. So a relevant comparison would be IBM 4341.
I have no idea how 4341 CPU speed compares to 8088 or to 68008, but it does
not look like it matters. Even if 4341 CPU was not that much faster, the whole
machine was in different class (more like 2-3 classes above) due to 16 MB and
bigger, faster HDs.

> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On 7/10/2023 2:33 AM, Terje Mathisen wrote:
> John Levine wrote:
>> According to BGB  <cr88192@gmail.com>:
>>>> The original 68000 came in 16 and 8 bit bus versions, just like the
>>>> 8086 and 8088.
>>>>
>>>> Legend says that if Moto had been able to ship the 68008 in quantity,
>>>> IBM would have used it in the IBM PC rather than the 8088. If only.
>>>
>>> I guess a question is if it had been used in the PC instead of x86, if
>>> Motorola could have then made it performance competitive with what later
>>> x86 systems became?...
>>
>> Hard to say.  At that point Intel just executed better than Moto.
>>
>>> OTOH, the instruction encoding does seem at least cleaner than x86...
>>
>> No S* Sherlock.  And the huge win of flat rather than segmented
>> addressing.
>>
>>> I guess another mystery could have been if a 32-bit RISC design could
>>> have been made more viable with an 8 or 16 bit memory bus?...
>>>
>>>  From what I can gather, processors from that era didn't really use L1
>>> or L2 caches though. This wouldn't likely bode well.
>>
>> Cache? What's a cache? The PC was shipped in 1981 and the first
>> general purpose CPU chips I know with a cache were the 68030 in 1987
>> and i486 in 1989.
>
> That 486 had a combined code/data cache of just 8 KB, and that was still
> enough to make a huge difference:

Yup. Since we all know that increasing cache size is a diminishing
returns game, it logically follows that the first bit of cache provides
the most return, i.e. performance gain.

> I had written a near-perfect
> Game-of-Life competition entry: If the target had been the 386 I might
> have won, but with the 486 David Stafford came up with an algorithm
> which could fit most of the problem space inside those 8 KB. I the end
> his entry ended up twice as fast as my code.

I certainly believe that. I recall that some time ago we had a
discussion here about sort algorithms, and someone pointed out a paper
that showed (on DEC ALPHA, IIRC) a cache aware algorithm that
significantly outperformed any non cache aware algorithms.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/9/23 13:57, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> I think that the 16-bit memory interface of the 68000 meant that they
>> wanted to have many instructions that fit in 16 bits, and with more
>> than 8 registers this becomes difficult (see also the PDP-11). The
>> 8086 is an example that trying to fit useful instructions in 8 bits
>> leads to even more limitations.
>
> This is a bit into an alternative past...
>
> A load-store architecture with 16-bit instruction words could have
> 16 registers, a = a op b instructions. This would leave 256 opcodes.
>
> However, a strict 16-bit word would probably not work too well
> well because lack of constants, the familar RISC problem made more
> pressing by having fewer bits. Putting in "load register lower" and
> "load regster upper" might have been possible, but would have
> eaten into the opcode space big time. More flexibility could
> probably have been achieved using one register as second operand
> as marker for a constant following in the instruction stream.
>
> It might be fun to design an alternative to the PDP-11, but one
> should not forget code size: In the days of core memory, memory
> was _really_ expensive. I am not sure how such a proto-RISC
> would compete on code size.

Yes, a 16-bit instruction word with 16 registers is possible. And yes,
constants were a bit of a problem.

See Motorola (then Freescale, then NXP) MCore. The Chinese licensed it
and called it CCore. There is even a Linux port to it.
I designed the original instruction set.

Brian

According to Michael S <already5chosen@yahoo.com>:
>> IBM wanted an intentionally crippled/low-performance system that would
>> not compete in any way with their small/medium systems?
>
>According to my understanding, when IBM PC project started S/370 models 125
>and 135 were already obsolete with annual sails close to zero.
>4331 was a flop on its way out. So a relevant comparison would be IBM 4341.
>I have no idea how 4341 CPU speed compares to 8088 or to 68008, but it does
>not look like it matters. Even if 4341 CPU was not that much faster, the whole
>machine was in different class (more like 2-3 classes above) due to 16 MB and
>bigger, faster HDs.

The whole point of a mainframe is that it has "balanced" performance
between processor and peripherals, and is designed for high
reliability. A PDP-8 had a much faster CPU than a 360/30 but people
bought a /30 because of its card, print, and disk peripherals, and
CE support to keep it running, and because it ran IBM software.

The 4341 was 2 or 3 times faster than a 370/148 depending on workload
but more importantly, it had 2 or 4 meg of memory, paging to support
multiple virtual machines, a string of 300MB disk drives. and a 1000
LPM printer. The early PC had maybe 256K, a couple of 360KB floppies,
and a pokey dot matrix printer.

Later on IBM made several PC add-in cards that ran 370 code. They
worked fine but sold poorly because nobody wanted to run mainframe
software on PCs.

There was also System/32, a small business system.with 16 to 32K of
memory, a 5 to 13 MB hard disk, and a line printer. It sold quite well
despite being slower than a PC, due to the peripherals and the
business software.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 7/9/2023 8:56 PM, MitchAlsup wrote:
> On Sunday, July 9, 2023 at 8:21:35 PM UTC-5, BGB wrote:
>> On 7/9/2023 6:44 PM, MitchAlsup wrote:
>>> On Sunday, July 9, 2023 at 5:57:47 PM UTC-5, BGB wrote:
>>>> On 7/9/2023 3:38 PM, MitchAlsup wrote:
>>>>> On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
>>>>>> On 7/9/2023 10:34 AM, Anton Ertl wrote:
>>>>>>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>>>>>>> The Motorola 68000 divided the 16 registers it did provide into two
>>>>>>>> groups; the general registers and the address registers. So it needed
>>>>>>>> three-bit fields to specify a register in either group.
>>>>>>>>
>>>>>>>> The Motorola 68000 was a CISC processor; it didn't "need" more than
>>>>>>>> eight registers in a register bank.
>>>>>>>
>>>>>>> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
>>>>>>> general-purpose registers.
>>>>>>>
>>>>>>> I think that the 16-bit memory interface of the 68000 meant that they
>>>>>>> wanted to have many instructions that fit in 16 bits, and with more
>>>>>>> than 8 registers this becomes difficult (see also the PDP-11). The
>>>>>>> 8086 is an example that trying to fit useful instructions in 8 bits
>>>>>>> leads to even more limitations.
>>>>>>>
>>>>>>> Another example is the RISC-V C extension (16-bit wide instructions),
>>>>>>> where a number of these instructions can access only 8 of the 32
>>>>>>> registers of the architecture.
>>>>>>>
>>>>>> FWIW:
>>>>>> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
>>>>>> encodings.
>>>>>>
>>>>>> However, in both ISA's, they are effectively Load/Store with typically
>>>>>> only 2R encodings for the 16-bit ops.
>>>>>>
>>>>>> In my case, there are some 16-bit ops with access to R16..R31, but
>>>>>> mostly limited to special cases:
>>>>>> MOV, ADD
>>>>>> MOV.{L/Q} (SP, Disp4), Rn
>>>>>> ...
>>>>>> Nothing in 16-bit land has access to R32..R63 though.
>>>>>>
>>>>>>
>>>>>> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
>>>>>> space. But, arguably this doesn't seem terribly worthwhile as the "hit
>>>>>> rate" for being limited to 8 registers is lower than that for being
>>>>>> limited to, say: "Rn=Rn+Rm;" and similar.
>>>>>>
>>>>>> Comparably, both RV-C and Thumb had a lot of hair in terms of their
>>>>>> 16-bit encodings as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
>>>>>> operations, but paid for this by having an absurdly small opcode space
>>>>>> (with a lot of instructions being encoded by playing trickery with the
>>>>>> register fields and addressing modes).
>>>>>>>> Providing 32 registers is something
>>>>>>>> RISC processors do - for them, it's worth the opcode space, because
>>>>>>>> opcode space is saved elsewhere
>>>>>>>
>>>>>>> No, it's because they have the opcode space. All those with 32
>>>>>>> registers have 32-bit memory interfaces and therefore could afford
>>>>>>> 32-bit instructions, so they could afford encoding registers in 5
>>>>>>> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
>>>>>>> instructions, but only 16 GPRs (maybe due to area concerns, maybe
>>>>>>> because the 801 only has 16 registers), and used the extra bits for
>>>>>>> stuff like shifts or conditions.
>>>>>>>
>>>>>> In my case, I have some encodings (and an operating mode) which have
>>>>>> 6-bit register fields, conditional execution, etc.
>>>>>>
>>>>>> But, compared with most RISC's (with a 32-bit instruction size), mine
>>>>>> has comparably small immediate fields.
>>>>>>
>>>>>> Though, interestingly, XG2 Mode has typically the same sized immediate
>>>>>> fields as SH-5 (which also had 6-bit register fields).
>>>>>>
>>>>>> Baseline mode only has 5-bit register fields for the most part, whereas
>>>>>> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don't see the smaller immediate fields as too big of a loss though:
>>>>>> There is a reasonably good hit-rate with the current immediate fields;
>>>>>> The ISA design does not overly penalize cases where an immediate can't
>>>>>> fit in the immediate-field;
>>>>>> There are also Jumbo prefixes.
>>>>>>
>>>>>> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
>>>>>> typically looking at a 3 instruction fallback case.
>>>>> <
>>>>> I think they (THEY) would argue mostly 1 becomes 2 instructions.
>>>>> Almost all displacements greater than 12-bits become a 2 instruction
>>>>> sequence; THEY would argue that this is where most big immediates
>>>>> come from.
>>>>> <
>>>> Well, say, you have:
>>>> XORI X10, X11, 511 //OK, fine.
>>>> Vs:
>>>> XORI X10, X11, 65521 //Now what?
>>>>
>>>> You get, maybe:
>>>> LUI X5, 16
>>>> ADDI X5, X5, -15
>>>> XOR X10, X11, X5
>>>>
>>>> This is kinda weak...
>>>>
>>> I agree with you that it is weak.
>>>>
>>>> Meanwhile, in BJX2 (without jumbo), you can fake, say:
>>>> ADD R4, 16777213, R7
>>>> As a 2-op sequence:
>>>> LDIZ 16777213, R0
>>>> ADD R4, R0, R7
>>> <
>>> Even::
>>> <
>>> ADD Rd,Rs,#0x123456789abcdef
>>> <
>>> Is 1 (One, single) instruction. It occupies 3 words, but it is 1 instruction.
>>> <
>>> So is::
>>> <
>>> STD #0x123456789abcdef,[Rd,Rs<<3,#0x123456789abcdef]
>>> <
>>> 1 instruction, this time it occupies 5 words, but it remains 1 instruction.
>>> RISC-V code for this is atrocious.
>> Yeah...
>> BJX2 can't do this either.
>>
>> With jumbo encodings, one can at least do:
>> ADD R4, 0x12345678, R7
>> As a single 64-bit instruction.
>>
>> Could in theory do:
>> ADD R4, 0x123456789abcde, R7
>>
>> As a 96-bit encoding, if it were common enough to justify the LUT cost
>> of enabling it. Granted, these exist implicitly if one enables the SIMD
>> vector immediate values, since the SIMD immediate values need the same
>> mechanism.
>>
>>
>>
>> Still no 64-bit displacements, mostly for timing reasons.
>>
>> Despite there being a 96-bit mode, only the low 48 bits are subject to
>> address calculation, and only with a 33 bit displacement.
>>
>> The compiler can mostly gloss over this though, seeing if a person uses
>> 'long' as an array index.
>>
>> Though, annoyingly, this does mean that it needs to end up falling back
>> to a slower case if one uses 'size_t' or 'ssize_t' rather than 'int' for
>> their array index.
>>>>
>>>> Which is part of why I burnt such a big chunk of encoding space on a
>>>> "Load Imm24 into R0" instruction; 2 actually:
>>>> LDIZ Imm24u, R0 //Zero-Extend
>>>> LDIN Imm24n, R0 //One-Extend
>>>> Which can be seen as a virtual:
>>>> MOV Imm25s, R0
>>>>
>>> You are still wasting instructions pasting bits together that can be "had"
>>> and a constant. This consumes pipeline cycles, registers, forwarding
>>> energy,... There is no cheaper way to deliver an operand into calculation
>>> than as a constant.
>> As noted, this is excluding "jumbo", which eliminates most of the
>> multi-op bit-pasting, but isn't regarded as part of the core ISA in the
>> smaller profiles (and didn't exist in early forms of the ISA design).
>>
>>
>> Then again, one option could be to promote the jumbo prefixes to the
>> core ISA, in a similar way to what happened with predicated instructions.
>>
>> Early on, I realized that the underlying logic for predicated
>> instructions was still needed for conditional branches, so there wasn't
>> any good reason *not* to promote it to core.
>>>>
>>>> But, it sort of paid off as this instruction left encoding space that
>>>> could also be used for things like Jumbo Prefixes and PrWEX encodings,
>>>> which in some of my other design attempts I had attempted
>>>> (unsuccessfully) to conjoin them with the Branch instructions (where
>>>> trying to WEX a branch instruction is also invalid in my designs).
>>>>
>>> Yes, go ahead and pat yourself on the back for something I consider
>>> to be poor.
>> Well:
>> MOV Imm25s, R0
>> Is sort of a sledgehammer solution, but like, it is workable in the
>> majority of cases...
> <
> MOV Rd,#123456789abcdef
> <
> works in all cases..........

On Sunday, July 9, 2023 at 9:51:48 PM UTC-5, BGB wrote:
> On 7/9/2023 3:41 PM, John Levine wrote:
> > According to BGB <cr8...@gmail.com>:
> >>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
> >>>
> >>> Legend says that if Moto had been able to ship the 68008 in quantity,
> >>> IBM would have used it in the IBM PC rather than the 8088. If only.
> >>
> >> I guess a question is if it had been used in the PC instead of x86, if
> >> Motorola could have then made it performance competitive with what later
> >> x86 systems became?...
> >
> > Hard to say. At that point Intel just executed better than Moto.
> >
> Could be.
> Either that, or there was some architectural factor at play.
<
Cost !!
8088 was in a smaller package than 68008.
<
> >> OTOH, the instruction encoding does seem at least cleaner than x86...
> >
> > No S* Sherlock. And the huge win of flat rather than segmented addressing.
> >
> That hardware x86 decoders work at all is kind of impressive in a way...
> >> I guess another mystery could have been if a 32-bit RISC design could
> >> have been made more viable with an 8 or 16 bit memory bus?...
> >>
> >> From what I can gather, processors from that era didn't really use L1
> >> or L2 caches though. This wouldn't likely bode well.
> >
> > Cache? What's a cache? The PC was shipped in 1981 and the first
> > general purpose CPU chips I know with a cache were the 68030 in 1987
<
A whooping 256 bytes
<
> > and i486 in 1989.
<
A whooping 8K bytes.
<
You forgot Mc88100--88200 was a 16KB 4-way set associative cache
with 64-entry fully associative TLB in '88-or so.
<
> OK.
>
> As can be noted, my familiarity with computers from that era is a bit
> sketchy at times...

According to MitchAlsup <MitchAlsup@aol.com>:
>> > Cache? What's a cache? The PC was shipped in 1981 and the first
>> > general purpose CPU chips I know with a cache were the 68030 in 1987
><
>A whooping 256 bytes
><
>> > and i486 in 1989.
><
>A whooping 8K bytes.
><
>You forgot Mc88100--88200 was a 16KB 4-way set associative cache
>with 64-entry fully associative TLB in '88-or so.

You're right, I did, but in fairness, so did everyone else.

Never actually saw an AViiON.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly