jecel

Thanks for pointing it out. Not having clicked on the link I had assumed it was about the second Byte issue that had a bunch of Smalltalk articles. Looking it up I see that that one was from 1985:

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

The August 1986 Byte issue on "Object-Oriented Languages" had another article on Smalltalk that was expanded into a nice book:

https://archive.org/details/byte-magazine-1986-08

https://rmod-files.lille.inria.fr/FreeBooks/Taste/

Slang is Smalltalk-80 written as if it were C: all methods in a single class so they can be translated to C functions, no object allocations and so on.

This means that you can run the code as Smalltalk-80 inside Squeak and use all the tools like the Smalltalk debugger. When you are sure that it is working, you translate it to C and compile it to machine code. Now you would use GDB to debug that but in theory you won't have to as the code should just work.

Note that running the Slang version of the VM inside Smalltalk-80 gives you a fully functioning Smalltalk that is about 600 times slower than the Smalltalk it is inside of. The idea for Squeak was that machines had become so much faster than in the 1970s/1980s that even with this slowdown you could actually use the simulated Smalltalk enough to find all bugs.

On earlier computers such a simulation would be so slow that it would take many minutes for a menu to be drawn on the screen when you pressed a mouse button, for example. You would not get enough done to run into all the bugs. By the late 1990s this was no longer the case.

There are cheaper options than $10K (see Mosis or Europractice price tables) but they have smaller areas (to be cheaper, you can have larger chips if you pay more) and might require commercial tools and NDAs. The process options range from much older than the Skywater one to reasonably recent technologies (with proportionally higher prices).

The main goal for Slang was to be able to use the Smalltalk debugger instead of something like gdb. Since you are essentially writing C but with a Smalltalk syntax the code itself is not any simpler, so it is all about the tools.

I enjoy using stuff for things they were not created for. In my HN profile I claim to be a hacker in the old sense of the word, and this is a big part of old style hacking.

But I am not then surprised when it takes a lot more effort than using something that had been created for that would take. For example, in 1983 I wrote a fancy Logo implementation using TI99/4A Extended Basic. It was far more complicated than the implementation I wrote in C. But the Basic version actually ran while the C version was just on paper since I didn't have access to any computers with C at the time.

I think it is great that people end up doing in Scratch things that you would expect would need Python or something like that. But if some 5 line Python program becomes a monster in Scratch, that is to be expected. The opposite is also true: a 5 line Scratch program might take pages of Python to replicate.

It is great that Scratch can be used as an introduction to programming, but that is not why it was created. It was part of the MIT MediaLab "Computer Clubhouse"[1] project where it would be used to enable a remix culture of cute animations and even simple games. Scratch's implementer, John Maloney, had already helped create a programming environment for kids called EToys[2] using Squeak Smalltalk, just as in the first versions of Scratch (later rewritten in Flash and then in Javascript).

So the comments about how it is hard to do in Scratch something that would be trivial in Basic or some other language are not surprising. It is an animation system that allows you to use programming to increment that.

As others have pointed out, a system with the same visual as Scratch but design for actually programming is Snap![3] so it is just a matter of using the tools for what they were created to do.

[1] https://web.media.mit.edu/~mres/papers/Clubhouse/Clubhouse.h...

[2] http://squeakland.org/

[3] https://snap.berkeley.edu/

Actually, the NeXTStep style was adopted by Windows 3.1 and that made it look subtly different from 3.0. Given the timing, I think the actual direct influence on Windows 3.1 was Motif, which in turn was inspired by NeXTStep.

When the NeXT was announced I thought it had been influenced by Randy Smith's (Xerox Parc) ARK (Alternate Reality Kit):

http://worrydream.com/refs/Smith%20-%20Experiences%20With%20...

But it might just have been a coincidence.

The IBM guys had gone to Seattle expecting to license CP/M. Their "benchmark" (in business terms) was the Apple II with Microsoft's Z80 SoftCard running CP/M. As far as they could tell, Microsoft owned CP/M. Bill Gates told them otherwise, phoned Gary Kildall but had to be vague and then sent the IBM guys on a plane to California. I can only guess they were pretty upset even before they ever got to DRI.

People's memories of what happened vary. One of the IBM guys claimed no meeting happened and they went back to Seattle even more upset (which is the most popular version). Gary claims that after some back and forth between Dorothy and her lawyer she did sign the NDA and that he arrived towards the end of the meeting and had a nice chat about the technical side with the IBM people.

The PC was launched with a choice of three operating systems: PC-DOS (the licensed MS-DOS), CP/M86 and UCSD Pascal. But the first cost less than a third of the other two.

In 1979 my high school friends and I used to play a game on paper that was essentially "light cycles". We used a sheet of graph paper and took turns extending our previous walls (each drawn with a different color using a fancy four color pen) by one more square.

None of us has access to computers back then, though our science fair project that year was a microprocessor based video game (using the Signetics 2650). We ran out of time to implement our own games, but "cycles" would have been our second right after "pong".

I did not think of having a character at the leading edge of the wall until I watched "Tron", however. And then I did implement it like that on my TI99/4A including the movie's theme music.

While I couldn't find the name of the paper version of the game we played, it seems that there was already a two player arcade version in 1976 called "Blockade" by Gremlin.

I was not able to find the reference and I didn't read it carefully back then so might have misunderstood what was being proved.

It has been a very long time since I read the book, but if I remember correctly the first message was actually found in base 11 (a picture of a circle).

Back then it hadn't been decided yet if the distribution of the digits of pi are such that all finite numbers can be found in it or not. Some years ago I read about some proof that they can. That means that "Carl Sagan was right!" in whatever encoding you like can be found in pi is you look deep enough.

The thing is what does "deep enough" mean? If we consider some two digit decimal number, like 27, then the chance that it isn't the first two digits is 99%. The chance that it isn't the first two nor the second and third digits is 98.01% and so on. The chance of not finding it among the first 500 digits is less than 0.6%. But unlikely things can still happen, so finding a message "too near the start" might convince some people that pi was created by an intelligence but wouldn't really be a good proof.

Alan wanted what eventually became EToys for his Apple projects. They looked into doing it in Java but figured that digging the old Apple Smalltalk-80 out of the trash bin and cleaning it up would be less effort. So we got Squeak.

Then they did Etoys stuff at Disney and some other neat experiments. Then Alan moved on to 3D shared environments[1] and later to recreating personal computing in 20K lines of code[2]. The idea was to build it on top of Ian Piumarta's COLA[3][4] but to get something out the door they ended up using a stripped down version of Squeak instead. So moving on from Squeak is harder than Alan hoped.

[1] https://en.wikipedia.org/wiki/Croquet_OS

[2] http://www.vpri.org/pdf/tr2012001_steps.pdf

[3] http://www.vpri.org/pdf/rn2006001a_colaswp.pdf

[4] http://www.vpri.org/pdf/tr2006003a_objmod.pdf

This paper compares the "blue book style" bytecodes (also known as V3 bytecodes) with the new ones used by sista:

https://www.researchgate.net/publication/280793584_A_bytecod...

The idea in sista is to do all fancy optimizations in the image by translating bytecodes to different bytecodes. The VM (called Cog, in this case) just has to translate the bytecodes to native binaries on demand.

This requires new bytecodes, like unchecked fast primitive calls, so that sista can have Cog generate better binaries.

The title for https://squeak.org/ is "Squeak/Smalltalk"

But that "better than Smalltalk" would not be Squeak, so I still present the system to people as "Squeak Smalltalk".

While the goal of Pharo is to encourage research even while breaking compatibility (possibly making it not Smalltalk at some point in the future), Squeak is way more conservative. The various SqueakFest events that happened were actually mostly about EToys used by children and teachers and at least some in the Squeak community have keeping that running a priority.

Personally I do use Squeak to research future languages as Alan intended, and it is also a great tool for that.

While the 432 was a memory-to-memory CISC and the 960 a classic RISC, I do think they have a lot in common technically. A key difference is that the 432 uses positive/negative offsets to separate raw data and capabilities while the 960 had an optional bit 33 to do the same thing, which makes it far simpler to mix data and capabilities on the stack.

The "operating in hardware" is microcode in the 432 but RISC-friendly in the 960, but it is still there.

I am talking about the original 960MX here. Most of these features were dropped on the following 960 models, if I understood correctly. Those do not indeed have much in common with the 432.

I would say it was intended as the main processor for supercomputers. I did a design like that (though it ended up actually built with old 68020s we already had in stock to save money) and there were many others. Intel itself had some interesting machines.

But Intel realized that asking customers to jump from x86 to an incompatible architecture (either the i860 or i960) was too risky - they could just as well jump to a competitor's architecture instead. So they repositioned their RISCs as coprocessors. It is amazing that they forgot this not too many years later with the Itanium.

My Smalltalk processor project is going very well, though obviously this is not the place for details.

The i860 introduced many new ideas, some that worked well and were copied and others that turned out to be unfortunate. Using wide datapaths in a single instruction/multiple data (SIMD) scheme for graphics got copied by Sparc and then the x86 and others, for example.

A selling point was the floating point performance of a Cray 1, far above what other microprocessors could do. Pipelining was a key to this and, taking the RISC philosophy seriously, it was exposed to the software. The compiler had to schedule the instructions so that they didn't try to use a result from a previous instruction until the clock it finally came out of the pipeline.

The problem of an interrupt is that the pipeline is full of unfinished calculations. If you know you are going to return to the same task, you just freeze the pipeline, don't using floating point inside the interrupt and then restart everything when you return you restart everything.

If you are going to switch to a different task instead (Unix) then this is a really bad design. The kernel will have to manually flush the floating point pipeline to somewhere, then manually restore the pipeline for the new task and then return to it. The sequence to flush and restore the pipeline is really tricky and slow.

Is it intended? In a way, yes. High performance was the highest priority for this project. If you are switching your processor among a bunch of tasks then you really don't care about performance that much, do you? Running Unix on a supercomputer should be possible, but it doesn't have to be good. As long as when you focus on a single program it goes amazingly fast.

As far as I know the i960 was the follow on to the iAPX432 (a joint venture with Siemens called BiiN) and not at all related to the i860.

This led Intel to have three options for the future in early 1990s: x86, i860 and i960. They decided to bet on the x86 and moved the i860 to the graphics card and the i960 to the smart i/o cards.

Actually, my school has a very strict deadline and I missed it so didn't get the PhD. But there is that text and the slides of my presentation:

https://prezi.com/yhw-a3i0rnri/adaptive-compilation-for-an-o...

The focus for SiliconSqueak 3 was to have a small die area for the version without the ALU Matrix coprocessor. The inclusion of a total of 20KB of caches does bump up the transistor count by 20*1024*8*6 = 983,040 transistors all by itself though these tend to be far more dense than logic transistors. The rest of the processor is reasonably small.

The stack cache is organized as 32 word blocks that are aligned in memory on 32 word boundaries. At any instant pseudo registers t0 to t31 are covered by two blocks, named low and high. Adding the register number to the bottom 5 bits of the frame pointer gives you a five bit result plus carry. The carry selects between the low and high blocks while the five bit result is the word within that block.

When the frame pointer moves out of the low block, new low and high blocks are selected by following a linked list. This allows stack blocks from multiple threads to live side by side in the cache.

You might find some aspects of my SiliconSqueak 3 design similar to your ideas. The details for the instruction set can be found in the appendix of this 2015 text:

http://www.merlintec.com/download/jecel_phd_deposited.pdf

The basic idea is that each instruction mentions two operand registers and one destination register. There are 4 kinds for the first operand and the destination:

t0 - t31: actually map to the special stack cache. Changing the frame pointer will remap them to a different area, possibly causing a line to be reloaded.

i0 - i31: actually map to the data cache as the first words of the receiver. Changing the self pointer will remap them to a different area.

s0 - s31: control registers for DMA-like logic that allows values to be streamed to other processors or to memory

x0 - x31: a mix of registers that control the hardware, including the frame pointer and the self pointer. Also allow pushes and pops to the stack.

The second operand can be these as well, but can also be several kinds of constants and can (L0 - L31) fetch the literal values in the current method, which also allows indirect access to globals.

The stack cache operates on linked lists of 32 word blocks (the current frame can span two such blocks) so the hardware to map tN to a cache word only needs a five bit adder

The switch was 6809 to 68000 with 8 bit bus (like the TMS9900 in the TI99/4A) to keep Raskin happy that a machine was still cheap enough with only 64KB. The goal was to share some of the Lisa software. But having a very low cost Lisa got Jobs excited and he ended up taking over the project.

https://www.folklore.org/StoryView.py?project=Macintosh&stor...

In English "to compile" is defined as "produce (something, especially a list, report, or book) by assembling information collected from other sources." which seems like a good description of what A0 to A2 did.

It is a pity that when people started to build translators they didn't use that name but instead kept the now obsolete term "compiler".

And the Z80 had a 4 bit ALU. Note that the 68000 actually had three 16 bit ALUs and could crunch 48 bits per cycle, depending on what operations you were doing since one was a full ALU while the other two more simple adders/subtractors.

It also only implements 3 registers, not 16 (RV32E) or 32 (RV32I), though it might count as 4 since register 0 is hardwired to a 0 value.

But using the RISC-V instructions means that all kinds of existing tools will work just fine for them as long as their programs keep within the limitations. No need to write their own assemblers and such.

Here is a video of a recreation of that using an actual Altair:

https://www.youtube.com/watch?v=4EPmWvqZ0Rw

While it is nearly always true that implementing stuff in hardware doesn't help as much as software people would hope, there are interesting exceptions. The 1986 Smalltalk processor project from Canada, called Swamp, used the top two bits of the 32 bit word as a tag. If the bits were 00 or 11 then we had a 31 bit integer (which also happen to be valid 32 bit integers for addition and subtraction, no conversion needed), while 01 was an object pointer into the heap and 10 was a reference to the stack.

Deciding if a 32 bit value is an integer or not is awkward in software, which is why Smalltalk and similar VMs use other encodings. In hardware it is a single exclusive or gate.

The 8086 couldn't properly run C unless you were willing to limit yourself to 64KB (or three times that, if separating code, data and stack didn't hurt your application). To use the full address space you had to use non standard extensions such as "near pointers" and "far pointers" (Microsoft) or "@" as an alternative to "*" but for the ES register (QNX). On the other hand, the addressing modes using the frame pointer were really great for Pascal. Segments didn't bother Pascal at all and even on the 68000 based Mac, which had a C friendly flat address space, the system software pretended to have segments.

Growing segments from 64KB to 4GB was enough to allow the 386 to finally run the same C software as other processors like the VAX or 68000.

Smalltalk (Squeak and Pharo, perhaps Cuis as well) does run on the iPhone. At least at some time in the past there were a few apps in the Apple store which had been written in Squeak. The restriction was that it had to be impossible to break out of the app into the underlying Smalltalk. And the raw Smalltalk itself was not allowed in the store, but if you were a registered developer you could get it and load it into a small number of iPhones/iPads.