> On Jan 4, 2021, at 11:00 AM, emanuel stiebler via cctalk
> <[email protected]> wrote:
>
> On 2021-01-02 22:34, Fred Cisin via cctalk wrote:
>> On Sat, 2 Jan 2021, Liam via cctalk wrote:
>>> I'm not really familiar with SAGE machines. They were not as
>>> well-known in the UK, I think, being upmarket from the Apple ][ and
>>> IBM PC, both of which were eye-wateringly expensive by UK standards of
>>> the time.
>>
>> Possibly, they weren't aimed at the same target audience.
>>
>> Perhaps they were intended more to compete with machines such as PDP-11,
>> rather than Apple][ and IBM PC.
>
> I was working 1981 with pdp11s and VAX780. Then I heard/read about the
> 68000, had to have one of those. Simple programming model, flat address
> space and really good performance. Signed up at a startup in Germany in
> 1982, had a lot of fun with all of them(68000, '10, '20, '30, '40). We
> basically only sold to research/labs.
I was at DEC at the time, and I remember discussions around the office saying
"this is a VAX on a chip". The instruction set made it feel that way.
Not long after that, Apollo Computer was founded to build workstations using
the 68000. They found out the hard way it is NOT a VAX on a chip. The key
design error is that the 68000 had page access aborts, not page faults -- they
weren't restartable so you could not create virtual memory using its page
access flags. That mistake was fixed in the 68010. I vaguely remember that
Apollo worked around the issue by using a pair of 68000 chips running one cycle
apart, so when the abort hit on the lead one you could stop the trailing one
and fake a restartable page fault.
Some years later I wrote the fast packet handling code of the DECbridge 900 (?)
-- FDDI to 6 Ethernet ports. That used a 68040 at 25 MHz, and with careful
design it could process a packet every 8 microseconds (12 microseconds if the
destination address wasn't in the address cache CAM). One trick was a memory
system that did some operations on the rising edge and some on the falling
edge, i.e., effectively a "2.5 cycle" access. The other (mine) was to use the
fact that the 68040 had a "RISC subset" of instructions and addressing modes
that would run in one or two cycles, while the other instructions took MUCH
longer. By sticking to handwritten assembly language in the RISC subset I
could make it go very fast. It also required awareness of oddities like the
fact that branch-taken is faster than branch-not-taken, the opposite of pretty
much every other computer.
paul
