lisadraw

Ray Arachelian ray at arachelian.com
Mon Nov 6 18:52:21 CST 2006


Fred Cisin wrote:
> NO!!!!!!
>
> The slow speed of the Lisa software, DUE TO IT BEING in Pascal, was the
> REASON why the Mac aps were re-written in assembly.
>   

And lack of sufficient RAM to run the type of OS it had, and the 8Mhz
68000 CPU being slowed down to 5Mhz due to the video cycles, etc.
Mostly, though, because of the transitions between code and all the
pushing and popping of parameters onto the stack.

If you look through Lisa code from an application through the OS and
back, there are several layers you have to go through. A lot of times
you'll find an app calling some piece of code that's in a library, that
turns around calls another piece of code with the same parameters, which
in turns invokes a trap or an A-Line call, which switches to the
supervisor context, executes, whatever, and back out two or three layers
we go. It's very expensive.

Some of it is strange. Instead of using a RTS, some of the code reads a
long word into A0 off the stack while fixing A7 to indicate that the
value was popped off the stack, then, does a JMP (A0).

In some ways, you can also see the different styles of programming
involved. The machine code sticks out, because you can see it doing very
interesting things that make you go, why did they do that, and when you
look in the 68K User + Ref manuals, you get this lightbulb over your
head, and you learn how deep their thought processes were and how
optimize that bit of code is.

The stuff the compiler generates is very obvious. Lots of LINK/ ULNK
opcodes, lots of movement on the stack.

What's strange is that the Lisa OS has something like 4-5 ways of
calling various routines. Some of it is just a relative jump off A5,
others are TRAP #7, TRAP #5 which seem to be some sort of trampoline
into the OS routines. Weirder still is the way they wrapped 24 bit
addresses into the A-Line traps. Those are really JMP statements that go
into Supervisor mode. i.e. opcode A234 5678 is really a JMP to address
345678, but with supervisor on!

A lot of that stuff is not optimized and it shows. That's not to say
that it's a bad thing as it shows that different groups of people worked
on different stuff so there are many ways of invoking OS code. If they
optimized everything into some "One True Way" it would have been harder
to tell. There certainly was a lot of room to optimize though. That was
done at least with QuickDraw on the Mac, and mostly out of necessity.

If I had to make the statement, I would say that today's code is a lot
more like the Lisa's than the Mac's.


Anyway, back to QuickDraw. There's a nice article about it here:

http://www.aresluna.org/attached/computerhistory/articles/macintoshbyteinterview

Which contains these tidbits:

*Atkinson: *Like Quickdraw. I won’t even count the first runs in Pascal,
but the first runs in assembly language were running 160K bytes, before
I added a lot of the new features. It’s now down to 24K bytes with lots
more stuff in it. Character-drawing speed is one you look at for drawing
an arbitrary size character, an arbitrary starting pixel clipped to an
arbitrary area. We were running, when it was being developed on Lisa,
about 1000 characters per second the first time. Well, I got that up to
4000. Mac is running about 7000. That’s seven times 9600 baud. This is
typical of all of our software packages here. You go through, get the
best algorithms first, get the stuff right. Then crunch it down, make a
first pass in Pascal, get the algorithms right, find the cleanest
algorithms, find all the corners, and make sure they’re tested. Then I
translate it into loose assembly language to get down into assembly
language and get it working. Then I’ll go through and get all the bugs
out again, and I’ll go through and do fine register allocation to figure
out what’s the most important thing. This little baby, the 68000, has
sixteen 32-bit registers sitting there, and the way you get performance
out of that is to keep them full. Keep the registers full of important
stuff all the time. That’s the way you make this processor sing. So you
go down and you do register allocation, and then you don’t stop. Then
you feed it back, you get your people to use it.

Quickdraw was designed by “pull” from applications rather than “push”
from the design team. You provide a facility, watch the applications
group try to use it, understand where they misunderstood something –
maybe you’ve got a bad model, you want to make it simpler and cleaner –
or where they don’t have enough performance. And then you go back and
you measure, measure, measure, measure. Optimization without measuring
is wasted time. Find out where the application’s really spending time
and go whump on the code. And any other cases they’re very seldom using,
squeeze the down in size, and stretch the other ones. There’s always a
trade-off between size and speed. Stretch out the common cases, let them
be bigger and much faster, and then keep the generality by squeezing
down the infrequent cases. So play your odds. People draw characters in
OR mode, a whole lot, and OR mode is about twice as fast as the other
modes, so 95 percent of all characters are drawn in OR mode. Statistical
measuring of the use of the thing allows you to get much more
performance on your average throughput than you can, if you don’t go
back and measure. I think we all believe that system software should be
done in assembly language at this stage of the game because high-level
languages can’t give you the performance and the code density that you
can get out of assembly language.

...

*Jobs: *We took a 12K-byte Pascal program running on a Lisa and we said
we want to do this in 2K and make it faster. But we had that extra year
to do that. And we also had the motivation, of course.

*Atkinson: *When you’re writing assembly, you know each instruction is
going to take 2 microseconds, it’s going to take 4 bytes of memory. In
Pascal, you’re removed from that, so you don’t concentrate on
performance as much. When I’m doing I/O stuff in assembly language I
look at the theoretical maximum speed you can run at. Why not do it as
fast as you can possibly do it? Especially when you’re doing disk I/O
stuff. How fast can you get into an interrupt and out?

...
*Atkinson: *Most of the early people were recruited from Apple... and we
have a pirate’s flag that we sometimes put on the roof. The idea is
we’re pirates and we go around and try to steal the best we can from
anywhere we can get it, and mostly that’s been from Lisa. A lot of it’s
been from Lisa, but it’s true in initially putting together the team,
too; we try to get the best people we can from anywhere in the company.

...
There's more stuff here:
http://www.aresluna.org/attached/computerhistory/articles/macintoshsotherdesigners





More information about the cctech mailing list