3 ms·

The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put t

by kabdib 9y ago

The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put there specifically to improve the garbage collection behavior of the system. (The sub-page protections allowed better than 4K granularity of physical page sharing, which helped a lot, since RAM on the newt was always precious). The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.

mikelevins 9y ago
I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.
pvg 9y ago
Yes perhaps I should have said something stronger than merely 'facilitate' but 'MMU parameters were better for GC' is a long way from the Lisp machine hardware/software mindmeld. It's still, as far as I can tell, pretty much just a MMU, right?
- lispm 9y ago
  I think the main point was to have a more interactivity friendly GC than otherwise possible. Having the user notice GC pauses on an interactive computer - a tablet - would have been a problem. MCL provided an ephemeral GC using the MMU of the 68020 (external) or 68030/40 (integrated). It dealt with short-lived objects in main memory, avoiding virtual memory activity. A similar level of responsiveness probably was the goal.
- kabdib 9y ago
  On the other hand, the newt (Senior, anyway) was running Dylan on bare metal; you don't need to have fancy-pants LISP-accelerating hardware to do that. You just need to have the intestinal fortitude to write an OS and runtime in something not C :-)

by kabdib 9y ago

mikelevins 9y ago

I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.

pvg 9y ago

Yes perhaps I should have said something stronger than merely 'facilitate' but 'MMU parameters were better for GC' is a long way from the Lisp machine hardware/software mindmeld. It's still, as far as I can tell, pretty much just a MMU, right?

lispm 9y ago
I think the main point was to have a more interactivity friendly GC than otherwise possible. Having the user notice GC pauses on an interactive computer - a tablet - would have been a problem. MCL provided an ephemeral GC using the MMU of the 68020 (external) or 68030/40 (integrated). It dealt with short-lived objects in main memory, avoiding virtual memory activity. A similar level of responsiveness probably was the goal.
kabdib 9y ago
On the other hand, the newt (Senior, anyway) was running Dylan on bare metal; you don't need to have fancy-pants LISP-accelerating hardware to do that. You just need to have the intestinal fortitude to write an OS and runtime in something not C :-)