jecel

The OS (in 20K lines of code) is called "Frank" and in the talks where Alan uses it for his slides at one point he zooms out and you can see a cartoon Frankenstein monster in the top left corner.

You might find this list of Kay's talks interesting:

https://tinlizzie.org/IA/index.php/Talks_by_Alan_Kay

While most RISC-V implementations don't use microcode, it is an option if your priority is not performance. Here are just two examples:

https://github.com/gsmecher/minimax

https://github.com/brouhaha/glacial

> Interestingly, Bill Atkinson was sure he'd seen > something cool at the demo that he liked, so he > implemented it. It turned out that he hadn't > actually seen it.

In a little more detail: the Smalltalk MVC (model-view-controller) GUI had an overlapping windows scheme, but only the topmost window is active. Since it is topmost, it isn't partially covered by any of the others and updating it is trivial. Clicking any other window brings it to the top and only then is it updated.

Switching between windows was a lightweight operation which gave Bill the wrong impression that even background windows were being updated. That would have required clipping graphics operations by arbitrary shapes, which Smalltalk didn't do.

Bill spent a while figuring out how to do that and as a side effect could easily implement non rectangular windows, like the rounded corners that Steve Jobs wanted.

At the end of a talk at the EE380 course in Stanford with L Peter Deutsch, Allan Schiffmann tells a story about being at the launch of the Xerox Star. As more and more things were demoed, the guy behind him kept cursing very loudly. Allan got fed up with this and turned to tell the guy to be quiet - it turned out it was Steve Jobs.

The April 1982 issue of Byte magazine had a very detailed article about the Xerox Star: "Designing the Star User Interface" by Dr. David Canfield Smith, Charles Irby, Ralph Kimball, B

I learned Smalltalk-80 from the blue book after getting the basic ideas from the August 1981 issue of Byte magazine. The book has four parts: 1) the basic ideas behind the language 2) a reference for all the classes 3) a detailed example in the form of a framework for event based simulation 4) a reference implementation of the virtual machine

It was later released as the purple book without part 4 for people interested in learning Smalltalk-80 but not in implementing it.

The link for the blue book is from Stéphane's collection which includes many other books, including ones that some people might find easier to learn from:

http://stephane.ducasse.free.fr/FreeBooks.html

All Smalltalk history talks mention that APL was a major influence, and it didn't have operator precedence either. In addition, the Smalltalk-72 scheme of "parse as you go" would make implementing precedence really awkward.

Smalltalk-76 introduced a fixed syntax and does have a bit of precedence: unary > binary > keywords. All binary messages have the same priority, which given that you can define new ones avoids a lot of complexity at the cost of a few extra parenthesis.

An important part of C history is that in the early 1980s the IBM PC and clones became the most popular computer in the world and it was not really compatible with C. You could say your program was "tiny" and limit it to 64KB or fill your code with "near" and "far" pointers (if using Microsoft tools) or use @ instead of * (if using QNX tools), but the cost was not being able to port to/from the VAX/68000 world. All this went away with the 386, but without this problem it is likely that C would have overtaken Pascal even sooner.

It is not hard to say what is unique about C: it and Forth are the only high level languages with seamless access to memory. If other languages offer it at all, like PEEK and POKE and Basic, it is far more awkward and interrupts your flow. That might be a good thing - the ESPOL compiler mentioned in the talk would print a big fat warning "YOU MUST KNOW WHAT YOU ARE DOING!" after any line in your code doing C-like tricks.

Everyone I have talked to that remembers the movie as well as reviews I have seen think it is about genetic engineering. The only thing the movie actually shows is genetic selection. The scientist tells Vincent's parents that only their genes will be used, though selected such that if they tried millions of times they would be unlikely to naturally get such a good combination.

This list of Basic/keyboard expansions for early videogame consoles mentions Mattel getting fined by the Federal Trade Commission until it delivered the promised computer module to clients:

https://lady-eklipse.livejournal.com/6081.html

"immediately lost control of it because all its components except the BIOS were COTS" is also a good description of the Apple II, but Apple was able to mostly keep clones at bay in their key markets. I believe IBM could have as well, but didn't initially care enough (the PC was a small part of its business, but micros were 100% of Apple).

Note that they took out 7 patents on the PC AT (286). When their attempt to take back control via the PS/2 in 1987 failed, they spent the 1990s getting chipset makers and clone makers to license their patents. Had they tried this in the 1980s the industry might have gone in a different direction.

The term "dynamic compilation" was popular in the Smalltalk community due to the 1984 paper by Deutsch and Shiffman that described what became the ParcPlace Smalltalk.

In Self 1 and 2 we also used dynamic compilation and we got adaptive compilation in Self 3. This moved from Sun to Animorphic for the Strongtalk project and got bought by Sun to become the Java HotSpot technology.

JIT was very popular among Japanese car manufacturers and the term was borrowed for Java. Note that Java only had simple interpreters in its first few years so we are talking the late 1990s here.

That already went to the Moon (sort of - see the difference between Block I and Block II AGCs):

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

The software fad of the late 1970s was modular programming as seen in Ada or Modula-2. Intel supported that with its 286 and it was a key feature of the National 32016, so Motorola couldn't be left behind and added support in the 68020.

Except that by the time the 68020 came out Unix and C were king and C's dirty hack solution to modularity (#include .h files) was now considered good enough. Intel and National kept full backwards compatibility (to this day, in the case of Intel) but Motorola quietly dropped the stuff from the 68030.

Intel actually bothered to copyright the mnemonics for the 8080 assembly language, so Zilog used the same binary instructions for its Z80 but different names at the assembly level. They had many more instructions, so having a different naming scheme (LD for a lot of stuff that were different names in the 8080) helped keep the complexity reasonable.

http://popolony2k.com.br/xtras/programming/asm/nemesis-lones...

Transmeta announced their first product, the Crusoe processor, in 2000. Before then they were highly secretive and nobody knew what area they would compete in.

Intel was indeed worried about the laptop market when the Crusoe came out, but quickly adopted the voltage and frequency scaling into their own processors negating some of Transmeta's key technical advantages.

Meanwhile, IBM changed directions as a third party fab (they dropped bulk CMOS to focus on SiliconOnInsulator) leaving Transmeta without a product to sell until they could find a new fab and design their next generation product for that.

Thanks for the correction - I fixed the list. I do note that github lists Dan's project as 81.6% C and 17.1% C++. Yours is indicated as nearly all C++ plus some Lua.

This is just a start - there is quite a bit to improve on that list.

Little Smalltalk is great and I highly recommend it. But it and GNU Smalltalk only give you access to the bare language itself, while Smalltalks with graphical user interfaces given you a very different programming experience.

I am trying to compile list of the many different Smalltalk implementations:

https://github.com/jeceljr/SmalltalkSurvey

Are you sure it was Ada and not APL like in the Ampere WS-1 from the ad on this page?

https://archive.org/details/byte-magazine-1985-05-rescan/pag...

Digitalk's Smalltalk V was pretty good at this. You got a nearly empty v.exe file which called a bunch of .dll files which contained the various parts of the standard image. Anything you did yourself would be added to v.exe so when you were ready to ship you just had to send the client that plus a subset of the .dll files (enough for your application to run, but not the development environment).

For a short while in the 1990s Smalltalk V/Win was available at no cost with the name Smalltalk Express.

Small (and not important) correction: the original Mac floppies were 400KB and went to 800KB in the Mac Plus. The Apple II floppies were 140KB.

AppletTalk was 0.23 Mbps.

Arcnet was a token bus (like IEEE 802.4 from General Motors' MAP) and not a token ring (like IEEE 802.5 from IBM's Zurich research).

And also in the old Animated Series.

https://memory-alpha.fandom.com/wiki/Yesteryear_(episode)

I am familiar with that as "The Law of Recapitulation" based on a discarded idea from Biology. I can't find any references now, but the idea was that the evolution of mainframe computers (memory sizes, features such as caches, and so on) was repeated years later by minicomputers and even later by microcomputers. Knowing this I was able to design very advanced micros in the early 1980s since I knew what the future would be like.

"The Wheel Of Reincarnation" described by Ivan Sutherland is closely related, but is based on the idea that computing history is more like a spiral than a straight line, so the future is more similar to the past than to the present.

http://www.cap-lore.com/Hardware/Wheel.html

While you can implement message passing on top of any language, as you said, I was talking about doing message passing under Smalltalk-80.

There are non messaging parts in Smalltalk-80, like assignment. The Self variant of Smalltalk goes quite a bit further in using message passing for everything.

As a counterpoint, I would suggest looking at Jeff McAffer's CodA project. It defined a group of 7 metaobjects to define the behavior of each object, six of them for message passing and one for accessing state. He couldn't patch the commercial VisualWorks virtual machine and used #doesNotUnderstand: tricks to make his prototype work. It wasn't fast, but showed that the semantics were correct. Here are the message passing metaobjects he defined:

- Send: prepares a message to be sent and negotiates with the receiver

- Accept: negotiates with the sender

- Queue: can save accepted messages to be handled later

- Receive: deals with queued messages

- Protocol: can associated the selector in a message with executable code

- Execution: knows how to used system resources to actually do what the message asked

The default metaobjects are 100% compatible with Smalltalk-80 base level code but his thesis show several interesting alternatives.

The original name for Smalltalk was "Slogo" for "Simulation Logo" (like Simula was for simulation in Algol). It also reflected the expected performance of the first implementations.

http://worrydream.com/EarlyHistoryOfSmalltalk/

Actually, all of the open shuttles have been full with the last few oversubscribed by larger and larger margins (about 100% for MPW6 if I remember correctly).

It was the commercial shuttles, called ChipIgnite, that have had space left over.

Unless I am remembering C wrong, this would work but the

   for (size_t i = length; i-- > 0 ; ) ...

that several other people posted would not execute for index 0. Shouldn't it be this instead?

   for (size_t i = length; --i > 0 ; ) ...

Just a guess, but before everybody adopted ARM the ST20 that was inherited from Inmos was ST's high end microprocessor, though they had a bunch of other families with 8 bits and such.

An interesting experiment would be to re-implement the iAPX432 with the same resources as today's high end processors (caches, branch prediction, out of order execution, etc). A simulation would be good enough to run some benchmarks (though the old Ada compilers might be worth improving a bit as well).

My guess is that the performance would be very close to an ARM or x86 with the same silicon area.