lisadraw

Fred Cisin wrote: 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/macintoshbyteinte… 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? 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/macintoshsotherde…