In the Apple anniversary edition of this week in tech, Andy Hertzfeld said that almost all the original Mac apps were written in pure assembler, as the compilers for the 68000 weren't that advanced at the time, and they needed to wring out every last bit of performance from the platform. I'd assume the same would be true for the Lisa apps. It's a good episode to listen to, if you're into early Apple lore.

Richard wrote: http://www.twit.tv/48

On 6/11/06 21:48, "Don North" <ak6dn at mindspring.com> wrote: I'm assuming you mean the Lisa 1 here? My first Lisa was the 2/5 edition and shipped as a 512k machine, though to be honest it was a later version running MacWorks. Pretty useless as a LisaOS machine since some of the office apps need 1mb to run. -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?

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…

On 7/11/06 03:45, "Chandra Bajpai" <cbajpai at comcast.net> wrote: My own Lisa page has disk images for most things and David Craig was kind enough to send me copies of his CDs a few years ago. http://www.binarydinosaurs.co.uk/Museum/Apple/lisa/index.php *seethes with jealousy* :) -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?

Wouldn't that be declared "volatile" then? Rich Rich Cini Collector of classic computers Lead engineer, Altair32 Emulator Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/ Web site: http://www.altair32.com/ /***************************************************/ -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of jwhitton Sent: Monday, November 06, 2006 4:58 PM To: General Discussion: On-Topic Posts Only Subject: lisadraw Ethan, That is entirely too existential for me ;-) John

In article <20061106122449.E64970 at shell.lmi.net>, Fred Cisin <cisin at xenosoft.com> writes: Ironicly, when I was the TA for "Introduction to Programming using Pascal" at the UofU in 1988, they used LightSpeed Pascal for the Mac classic. It was kind of like TurboPascal/TurboC in that the compiler did everything in memory and was therefore quite fast. It had decent integration with the Mac Toolbox so you could do all your normal style Mac stuff. It was a pretty decent environment and I remember being impressed with it because on previous Pascal implementations I had used, I had considered them to be fairly lame. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html>

I'm curious why Larry Tesler and his team from Xerox Parc picked Pascal as the language to build Lisa on...esp. considering the Alto was a BCPL machine (forerunner of C). I know Apple was an early adopter of USCD Pascal...I wonder if had any influences. Did Apple write their own compiler? -Chandra Lisa 2/5 Lisa 2/10 Lisa 1 :-) 91 Lotus Esprit -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Fred Cisin Sent: Monday, November 06, 2006 3:29 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: lisadraw On Sun, 5 Nov 2006, Chris M wrote: MOST of the Lisa software seems to have been written in Pascal. Part of Job's "we want the next (sic) generation, NOT a repeat of what we already have!" philosophy that caused him to hire some CS graduates with NO experience in order to get a fresh approach. Some of them didn't even know that current Pascal compilers were designed for TEACHING programming, and did not produce output suitable for real world.