Analysis of Lisa Clascal source-code | Hacker News Reader

Analysis of Lisa Clascal source-code

eschatologist.net

62 pointssoapdog15 comments

FTA: Just like Macintosh, Lisa has a Memory Manager whose heap is largely organized in terms of relocatable blocks referenced by handles rather than fixed blocks referenced by pointers […] What I find interesting is that, unlike the Memory Manager on Macintosh, I’ve not seen any references to locking handles so they don’t move during operations.

I’m not sure that is correct. The Lisa had a MMU (http://bitsavers.org/pdf/apple/lisa/development_history/arti...), and swapped data into and out of RAM, and data may have moved to different addresses when swapped out and swapped in again.

The MMU is limited by the fact that it is bolted onto MC68000 which nominally does not support MMU in todays sense. The article you linked says that while code was on demand swapped ("paged" in UNIX terms) by OS (which they "empirically determined" to be possible on the CPU), data segments had to be swapped for process as a whole (with the process having ability to mark some of them as not needed at the time). This probably means that caring about how the memory model works was mostly opt-in for the user code. Original Macintosh does not have any kind of MMU and emulates this through software, which enables one to have "half-dereferenced segments" and thus requires segment locking.

The Lisa could run UNIX, unlike the original Macintosh.

https://en.wikipedia.org/wiki/Apple_Lisa#Third-party_softwar...:

> For most of its lifetime, the Lisa never went beyond the original seven applications that Apple had deemed enough to "do everything",[citation needed] although UniPress Software did offer UNIX System III for $495.[32]

> The company known as the Santa Cruz Operation (SCO) offered Microsoft XENIX (version 3), a UNIX-like command-line operating system, for the Lisa 2 — and the Multiplan spreadsheet (version 2.1) that ran on it.[33]

In hindsight. I wasn’t clear, but my comment was triggered by

> I’ve not seen any references to locking handles so they don’t move during operations.

That doesn’t make sense to me. If memory blocks never move, why go through the trouble and performance hit of double indirection?

That led to me guessing the MMU was involved, but it may not have been.

The Lisa did have movable memory blocks, though, at least in LisaWrite. https://www.folklore.org/StoryView.py?project=Macintosh&stor...:

“The Lisa word processor team had developed a memory manager with relocatable blocks, accessing memory blocks indirectly through "handles", so the blocks could be moved as necessary to reduce fragmentation.”

The hardware can do the segmentation model that was designed around what the OS needed, because of how it was designed, there is nothing that precludes you from doing your own additional handle/segment mechanism in user space. And well, there certainly was reasons why you would want to do that.

In theory, at least, swapping and paging are different ways to design a VM:

https://stackoverflow.com/questions/4415254/difference-swapp...

> Swapping refers to copying the entire process address space, or at any rate, the non-shareable-text data segment, out to the swap device, or back, in one go (typically disk).

> Whereas paging refers to copying in/out one or more pages of the address space. In particular, this is at a much finer grain. For example, there are ~250,000 4 KB pages in a 1 GB RAM address space.

Since swapping is obsolete, that term has fallen into disuse, but we're talking about obsolete systems here:

> Hardware-wise, swapping can be performed without any memory management HW whatsoever, although the early machines employed a simple memory mapping scheme (e.g. base and bound, or a simple one level fixed size page mapping table (e.g. divide the 64 KB data address space into 8, 8KB pages in a larger physical address space (256 KB ... 4 MB)).

> In contrast, paging requires page-granularity virtual memory page table entries, which typically encode the physical address of the page, PTE bits such as valid, read, write, etc. The machine also needs to automatically (transparently to the application program) fetch and interpret page table entries as necessary to map each virtual address to its physical address, and/or take a page fault exception to enable the OS to make the page accessible and/or schedule an I/O to load it to physical RAM.

The 030 was the first real MMU 68k.

The 68030 was the first implementation with an on chip MMU. The 68010 and 68012 could work with the 68451 segmented MMU and the 68020 could work with the 68451 (since it was a memory-mapped peripheral) and with the 68851 paged MMU.

In addition to Motorola’s MMUs, through the 68020 there were a ton of MMU designs ranging from Lisa’s software-assisted MMU (where a stack probe instruction is inserted into the function and trap prologues) to Apollo’s “run two 68000 CPUs out of phase for page fault recovery” insanity.

Pascal code is yellow on blue background.

I think it displayed correctly for me. Still I switched to reader mode for comfort, due to the small font size and narrow column.

Thats Turbo Pascal, right? Been there, still miss it.

I still maintain that Borland's text IDEs are the best ever produced. If I could have it today (+ a language server) I'd switch in a heartbeat.

Depends on which version. :)

I got to take a computer science course in high school. My teacher was one of the best I've had; she had been educated in the subject with punch cards, on the other side of the Iron Curtain. In the first class, she informed us that we would not be using the computers in the lab for the first half of the year. Half of the class dropped the course after that. I did not, and it changed my life.

Pascal for me will always be blue on a whiteboard, semicolons optional.

Reply on news.ycombinator.com