Re: Lisa Toolkit

From: Larry Rosenstein <lrosenstein_at_email.domain.hidden>
Date: Thu, 4 Jan 2001 17:19:12 -0800


Sorry for the long reply, but hopefully people will find this interesting.

At 4:54 PM -0700 1/3/01, David Craig wrote:

>which created these libraries. Stanford has a copy of this in its Apple
>archive in their special collections department. I am presently trying to

I didn't realize Stanford had a copy. I carried most of my Lisa technical documentation around from job to job at Apple (and even Taligent), but I finally got rid of it all when I left Taligent.

>learn which Toolkit methods were needed versus those that were not needed. I
>think Apple could have documented this area better since I recall wading

This is an issue with object-oriented frameworks in general. (MacApp had a similar problem.) Since the Toolkit was the first one Apple ever did, we didn't have any experience with the best way to document it. This is also one reason why the Toolkit shipped with source code.

>My understanding is that Lisa system calls were handled by the A-Line
>(1010-Line) instructions of the Motorola 68000 CPU. Each system call was an

Now that you mention this it is starting to come back to me. As I recall, the Lisa OS did use a small number of A-Line traps for things like cross-library calls. These calls had to trap into the OS so that it could, for example, load the proper code segment. (I believe the OS also changed the IUJSR to a standard JSR so subsequent calls would not have to trap into the OS.)

This isn't quite the same as on the Mac, where the A-Line instruction contains a trap number that it used to index into 1 of 2 trap table to find the ultimate address. Having a trap table allows for easy patching, but I don't recall the Lisa OS having such a mechanism.

>A-Line instruction containing 4 bytes with the first byte starting with hex
>A. The rest of the A-Line instruction contained the absolute address of the

I don't think that's right; an A-Line instruction on the 68K was only 2 bytes. I think an IUJSR "instruction" was probably a particular 2-byte A-Line instruction followed by 4(?) bytes that specified the routine being called.

>unit" manager which was a programming library whose purpose was to load (and
>I assume unload) intrinsic units. There were many intrinsic units which were

The issue here was that the 68000 had a problem with virtual memory in that the CPU didn't save enough state for the OS to be able to restart an instruction that got a bus error. (Normally, VM works by the OS intercepting the bus error, paging in the right code, and restarting the instruction.)

Other 68000-based machines handled this by having 2 CPUs one for normal execution and one for handling VM. On the Lisa, the OS team were able to figure out how to restart certain instructions and these were used to automatically manage some aspects of memory segments.

Code segment loading was automatic since cross-segment calls were done using the IUJSR, which trapped into the OS. I don't quite remember if code segments were automatically unloaded by the OS.

Data segments had to be manually managed, since there was no single instruction that was used for accessing data, and it would have been too hard to figure out how to restart all possible data-access instructions.

Stack segments were managed by the OS because the compiler inserted a TST instruction into each subroutine that "touched" the furthest stack address needed by the subroutine. The OS would automatically expand the stack segment based on this test.

>were fixed for each version of the Lisa OS. My understanding is that Lisa
>2.0 applications could not run under Lisa OS 3.0 and vice-versa due to this
>A-Line architecture. I recall reading that Apple planned to remove this
>restriction in a future Lisa, but that never happened. These system call

That's basically right although I don't think the 4-bytes after the IUJSR call were a memory address. I seem to recall that each intrinsic unit had an assigned number, and that the 4 bytes consisted of the intrinsic unit number and something that identified the desired function in the library. (Possibly an offset into the library or an index into a table.)

The latter piece of data was the thing that would change with each OS release, which is why applications needed to be rebuilt for each release. You're right that Apple was looking at a "stable and extensible library mechanism" that would allow existing apps to work with updated system libraries but that this never was finished.

>subroutine" and was a variation on the 68000's normal JSR instruction. These
>intrinsic libraries also shared the same memory address space which was
>seperate from application address spaces. This means an application could

I can't be certain, but I don't think that's quite right.

I think the intrinsic unit code was mapped into each application's address space. The reason for the IUJSR was not that the libraries were in a separate address space, but that an application could not be certain that the library code was loaded at the time it made the call. Instead it had to trap into the OS (using the IUJSR) so that the OS could load the code if needed.

(If the OS did indeed patch the IUJSR to be a normal JMP to the library code then that would indicate that the code was indeed mapped into each application's address space.)

>My understanding is that the original focus of Lisa software development was
>based on Apple writing all the applications. Dan Smith, a member of the Lisa

As Dan said, Apple changed its mind about whether the Lisa would be open or not. By the time I joined Apple, Larry Tesler was already thinking about 3rd party development.

>My understanding on this topic was Apple cancelled the Lisa internally
>before the Toolkit was completed which is the reason there were very few

That's true. I don't remember the exact time sequence, but Apple didn't cancel the Lisa right when the Mac was introduced. I think we started working on MacApp in the fall of '84, so the Toolkit training for outside developers probably was that summer.

>I also recall that there were a handfull of Toolkit-based programs created
>by outside companies that included the Calendar program Larry mentioned, the
>CompuGraphic desktop publishing program, the Lisa-to-Macintosh migration kit

Another of the developers that came in for training was thinking of a CASE (computer-aided software engineering) tool, but I don't think they got very far on it.

(I remember this only because one of my TAs from school happened to be one of the people that came out to Apple. We took some of the developers to a country-western bar in San Jose called the SaddleRack, and somewhere I've got a picture of us in front of their mechanical bull. And no, I don't think any of use actually rode the bull.)

-- 
Larry Rosenstein

- - - - - - - - - -
LisaList is sponsored by LowEndMac.com, MacLaunch.com, and...

MacResQ Specials: LaCie SCSI CDR From $99! PowerBook 3400/200 Only $879! 
Norton AntiVirus 6 Only $19! We Stock PARTS! <http://www.macresq.com>

Shop buy.com and save. <http://click.linksynergy.com/fs-bin/
stat?id=O7sajHhUCjc&offerid=13541.10000001&type=1&subid=0>

    /      Buy books, CDs, videos, and more from Amazon.com     \
   / <http://www.amazon.com/exec/obidos/redirect-home/lowendmac> \
- - - - - - - - - -
This message is sent to you because you are subscribed to LisaList.

List info               <http://lowendmac.net/lists/lisa.html>
Send list messages to:  <mailto:lisalist_at_email.domain.hidden>
To unsubscribe, email:  <mailto:lisalist-off_at_email.domain.hidden>
For digest mode, email: <mailto:lisalist-digest_at_email.domain.hidden>
Subscription questions: <mailto:listmom_at_email.domain.hidden>
List archive:           <http://mail.maclaunch.com/lists/>

Host your mailing list for free at Maclaunch
http://www.maclaunch.com/forms/list.shtml
Received on 2001-01-04 17:32:00

This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:18 EST