• Please review our updated Terms and Rules here

VAX/Smalltalk-80?

commodorejohn

Veteran Member
Joined
Jul 6, 2010
Messages
3,302
Location
California, USA
Just in the middle of getting a fresh OpenVMS install set up on my VAXStation (the original having been done years ago when I barely had any idea what I was doing,) and looking through various repositories for interesting software to put on there. I know from reading up that, back in the day, there were two implementations of Smalltalk-80 for VAXen - the first was Unix-based, done by an independent research group, while the second ran under VMS and was actually developed within DEC. This was referred to in the literature I've read as "VAX/Smalltalk-80" and it sounds like they may have made it available to outside parties - anybody know if there's a surviving copy out there, or what the story was on this?
 
Around 1982-1983, while working at DTD (Data Terminals Division) at HP, I remember doing some work at HP Labs to port Unix V7 to 68k based project. In the same room that I was working was a Vax 11/780 with a bitmapped display, mouse, keyboard connected to it and running Smalltalk. I believe it was a port from Xerox source code. I do remember a comment made bu the guys working with it that when running Smalltalk the VAX 11/780 made a nice single person workstation.
The back story as I recall was that Xerox licensed Smalltalk to three companies to try out, HP was one of them, I think DEC was another. I'm not sure who the third was, maybe Intel.

I'm sure someone else has more detailed info.
 
I actually got a copy of the source, courtesy of a fine fellow on the cctalk mailing list who got in contact with one of the authors and forwarded it over my way; I'm still waiting to hear back on getting their okay to put it up for public perusal, but it seems to me like something that probably ought to be on bitsavers or so.

Haven't gotten around to trying to build it yet; the intermediary party made the observation that it was developed on an older version of VMS and may need tweaking to work on 7.3, plus the display code is adapted to use the VT125/ReGIS rather than the more conventional memory-mapped framebuffer model (understandable, since that'd be a lot more accessible form of bitmap display in a typical VAXherd environment.) Good to know it's still extant, though...!
 
A
The back story as I recall was that Xerox licensed Smalltalk to three companies to try out, HP was one of them, I think DEC was another. I'm not sure who the third was, maybe Intel.

I'm sure someone else has more detailed info.

Tektronix Magnolia

This is covered in Krasner's "Smalltalk Bits of History, Words of Advice"
 
Thanks for digging this up, and for sharing. I installed it on my VAXstation 2000/GPX, running MicroVMS 4.7. It's... not a very polished product, is it? It drops to the debugger, for example, if it tries to draw into its window when any part of it is obscured by some other window. (Saving a snapshot also crashes with a DIGITAL-only opcode exception, but this doesn't happen on my 3100m76 so perhaps it's something specific to the uVAX II processor.)

Which brings me to what I wanted to ask you - is the UI ungodly slow for you? Like at least three or four seconds, sometimes 10 or more, redrawing screen objects one. at. a. time. every time you click the mouse or type a character in a window? It's even worse for the browser window, where there are 40 or so objects and it takes 20-30 seconds. I have the sense that under the covers the VAX Smalltalk-80 is reasonably quick, but the UI performance is intolerable. And incredibly, it's not noticeably faster on the 3100m76 (though it's clear that under the covers, computationally, non-ui stuff is about as much faster as one might expect). I wondered if it might be a color vs. monochrome graphics thing, but again, switching from the SPX to the monochrome display on the m76 only brings a barely noticeable improvement.

It struck me that there was no way that Alan Kay or Dan Ingalls would have tolerated UI performance like this through years of active development on the system, but it wasn't until I saw Dan's Alto Smalltalk-76 demo for CHM on YouTube that I was able to confirm - yeah, the Alto is much, much faster than the VAX, at least in the UI. It kind of made me doubly sour about DEC's complaint in the "Bits of History" paper that nobody would want to use Smalltalk because it's so slow --- I can't help but think, "yeah, and it's your fault, you muppets."

There are a few other things that struck me as odd, starting with the apparent inability to interact with the VMS filesystem for fileIn: or fileOutOn: type tasks. Do I have it right that it can only work with a disk-image type file, which itself is a container for all Smalltalk files?

The thing also slowly corrupts the offscreen storage of fonts on the VS2k, so after some time you can no longer use the terminal windows and have to (blindly) reboot to get them back. But this isn't unique to Smalltalk; other non-terminal UIS applications (such as SIGHT) do the same -- just an awesome "feature" of this old version of VWS (3.2 or 3.3 IIRC).
 
I haven't had a chance to try running it so I don't know about the specifics, but one thing I do recall from the "Bits of History" account is that they did notice serious UI bottlenecks owing to the fact that VAX/Smalltalk had to use ReGIS for display purposes, rather than the direct framebuffer access it had on the Alto. (I'm assuming DECTerm is doing the necessary interpretation on your GPX; it wouldn't have the same bandwidth bottleneck as a separate terminal, but it still would be slower than full framebuffer graphics.) I don't know how much work they put into adapting the higher-level display system to fit that, but I'm guessing "not a lot," as I definitely got the impression from the paper that this was only ever alpha-quality software done as an experiment.

It'd be interesting to rework the same core code into something like GNU/Smalltalk where the object system is decoupled from the GUI environment, just to be able to compare general interpreter performance vs. graphical bottlenecks.

And yeah, the whole "image" thing comes straight from the original Smalltalk model, where (as I understand it) essentially every object which hasn't been garbage-collected is counted as persistent and the disk is (as far as Smalltalk is concerned) really just a backing store/swap volume so that it's possible to have more than 128KB of stuff in the system. One's "image," then (in the original, the removable disk pack) is the snapshot containing everything Smalltalk knows or cares about for that particular instance of the system; it does have the concept of separate files, but they all live within the image. It's simultaneously one of the more interesting things about the design and one of the many reasons it had trouble catching on outside of PARC; it doesn't integrate well with more conventional models and I don't think there was ever a standard for living on other filesystems (until years later, when it had already been relegated to niche status.)
 
Last edited:
(I'm assuming DECTerm is doing the necessary interpretation on your GPX; it wouldn't have the same bandwidth bottleneck as a separate terminal, but it still would be slower than full framebuffer graphics.)

Well, no, the code is linked against UIS, the VWS UI toolkit. It has its own window and interacts directly with the mouse. The ReGIS emulation stuff happens in the terminal window. It'd be limited to 400 lines if it were ReGIS. Actually it's not clear to me that there's any support for VT125 left in that code, apart from the README which explains how to move the pointer using the arrow keys. I expect at one time there was a vthand.mac which implemented the VT125 handling; it appears to have been replaced by vthand.c, which is all UIS (and 5 years newer than the rest of the source).

And yeah, the whole "image" thing comes straight from the original Smalltalk model, where (as I understand it) essentially every object which hasn't been garbage-collected is counted as persistent and the disk is (as far as Smalltalk is concerned) really just a backing store/swap volume so that it's possible to have more than 128KB of stuff in the system. One's "image," then (in the original, the removable disk pack) is the snapshot containing everything Smalltalk knows or cares about for that particular instance of the system

Yes, the Smalltalk image is a memory image. But there are no files in it, at least not in the sense of data that can be instantiated as a FileStream object. Implementers were expected (though not in the sense of it being required of them) to provide their own classes for interacting with whatever the local filesystem was. This is the first Smalltalk system I've encountered that apparently doesn't -- any local file that is opened is scanned for a directory (rather than reading the filesystem's directory), and if it's not found you're not doing file I/O. You can see in the screenshot (this is leftover system state from whoever generated this image, not something I did) -- instantiating a Disk object from a VMS file 'smalltalk.fil' (not provided with what's been released), and then the File methods interact with this, instead of actual files on the VMS system. The System Transcript shows the "directory" of "smalltalk.fil", and it includes filenames which are (AFAIK) illegal in VMS.

vax-st80-uis.png
 
Back
Top