There's memory bandwidth and there's memory transaction thruput

Joachim Durchholz joachim.durchholz at munich.netsurf.de
Tue Feb 16 18:46:16 UTC 1999


sqrmax at cvtci.com.ar wrote:
> 
> Oh, but there are some LEA tricks that can help you do arithmetic with
> those registers I guess... something like (but with registers
> exchanged and never tried this myself):
> 
> LEA EAX, [EAX*4 + EAX] "Mul EAX by 5 in few clock cycles]

OK. Where's the segment register in that? :)

> Stuff like this is better described in Asmedit's help, available at
> garbo.uwasa.fi.

Agreed. And I won't pretend that I know all tricks. I just know what
doesn't work :} .

> >Actually the 68K processors always had a release date somewhat behind
> >that of the same-generation Intel processor, always had fewer bugs
> >(if any).
> 
> You should see the pdfs available at Intel showing the bugs of each
> revision of processors. The list doesn't contain a few, it's much more
> than that!!!

That is a relatively new concept. I remember the time when the '286 was
brand-new, and the engineers all said "don't use it yet, the processor
has too many bugs in it". That was when the 68000 had already been out
for a lot of time, had fewer bugs, and was as fast as an 80286 at the
same clock speed. Then Motorola brought out the 68020, which used less
cycles *and* could be clocked higher. Intel brought out the 80386 two
years later (I think, just guessing from memory now), which barely
caught up with the 68020.

> >However, 68Ks didn't run DOS, so Motorola lost that race, and
> >sometime after the 68030 they decided to leave the field to Intel and
> >didn't tune the clock speed to the levels that Intel uses today.
> 
> I'm really sorry about this... I liked the 68K more than the 8088.

You're one of a huge crowd. Well, the 8088 was less expensive than the
68000, and Motorola couldn't foretell that IBM's decision of processor
for a new line of smart terminals would determine the future of desktop
computing.

> >> (like asynchronous IO for instance, why do you think intel machines
> >> need FIFOs everywhere?).
> >Hmm... that's a feature that I didn't see in my 68K specs. What do
> >you mean with this?
> 
> >From where I read it, an text file from the amiga describing the 68K,
> it meant that the cpu could initiate port accesses without having to
> wait until completion, and so could go on executing stuff. I now think
> it has to do with the amiga's chipset that controlled 25 dma channels.

Right. I think it's the chipset, not the processor. Amiga had a
nicely-designed OS structure. They just had abysmal resource tracking
(IOW no garbage collection), so just about any program ate up a little
more resources until the machine locked up. Then you had to reboot.

> And PCs have 8... now all this causes the motherboards to have FIFOs
> everywhere because the bus is heavily used and/or the cpu will be
> flushing caches and losing thousands of cycles resetting itself...
> from Asmedit's clock cycle chart, flushing caches in a pentium
> processor needs 2000+ cycles, and context changes, mode changes and
> so on are described as performance killers. And so it can't pay much
> attention to IRQs and so data gets lost in the middle.

Ah. This explains some of the reliability problems.
But it's a PC mainbord design issue, not a processor issue.
Well, it's all market pressure. Nobody bought Amiga, so it went niche.

Regards,
Joachim
-- 
Please don't send unsolicited ads.





More information about the Squeak-dev mailing list