jecel

The original description of the method finder was by Ted Kaehler in the July 2001 issue of SqueakNews. That electronic magazine was implemented in Squeak, but can now run in your browser thanks to the SqueakJS virtual machine:

https://smalltalkzoo.thechm.org/SqueakNews/index.html

The Oberon book describes the compiler, operating system, windowing system and other things.

http://www.projectoberon.com/

Just adding processing steps requires more masks. Moving from visible light to smaller wavelengths requires more and more sophisticated materials for the masks with smaller and smaller imperfections.

To push a technology like DUV (deep ultra violet) further and further requires multi-patterning, which means several masks for a single processing step.

For EUV (extreme ultra violet) no material is transparent so the masks are actually mirrors. With 40 alternating silicon and molybdenum layers, each the exact thickness to match the 13.5nm wavelength, you can reflect enough of the EUV beam to get the job done. Making such a mask is a lot more expensive than one that is basically a glass photographic plate.

The time to actually write a mask has gone up by a large factor, as you mentioned.

The combination of all the factors increases the cost of the masks from a few thousand dollars for 1970s technology to many millions today.

They didn't do it in a smart way. Part of the Self group joined forces with some other researchers to create a company called Animorphic which would build the world's "fastest Smalltalk" using the Self technology. It was called StrongTalk and had other interesting features like optional type declaration and extensive use of traits and mixins.

Given the buzz around Java they did a quick demo showing that language running on top of their technology, and in 1997 Sun bought them to use that HotSpot technology in their main Java implementation. So they paid a lot for what they previously already had but ignored.

I only watched this from the outside, but my impression was that it was an overreaction. Sun had a nice research operating system based on Java called SpringOS, but when clients heard about that they revolted. The transition from SunOS to Solaris had been traumatic and they threatened to jump ship if there would be any more changes ahead.

Sun's reaction was to adopt "only Sparc, only Solaris, only Java forever and ever" as their roadmap, publicly killing SpringOS, Tcl, Self (programming language) and so on. That did make the clients happy.

Here is a 1978 paper "Compilation and delayed evaluation in APL":

https://dl.acm.org/doi/abs/10.1145/512760.512761

In the citations there is a 1970 paper "An APL Machine" which had some techniques which might or might not be considered a JIT.

One alternative is LCC:

https://en.wikipedia.org/wiki/LCC_(compiler)

It is half way in complexity between TCC and GCC or LLVM and was created to be educational. I think there are major differences between more recent versions and what it described in the book.

In terms of architectural style RISC-V is more similar to MIPS (via DLX) than to RISC-I, II, SOAR and SPUR (and Sparc).

Pete Foley worked on something similar while at Apple. See "Other Projects" at

https://web.archive.org/web/20190102164746/http://www.byrdsi...

and the picture "Turbo 6502" in the slide show at the bottom of that page.

In 1985 I was hired by a company in Brazil to decompile QNX to commented C sources. Softec launched the first PC XT clone in Brazil in May 1983 but it was initially absurdly expensive ($15K for a configuration that was $5K in the US) so they sold it with QNX telling clients they could add up to 5 terminals to divide the cost by 6 users. Most clients preferred to pirate MS-DOS instead, but a few did pay for Analix (the 1977-1992 reserved market policy in Brazil forced them to claim to have written it themselves instead of licensing it from Quantum Software Systems).

One problem with saying they had written it was that clients would report bugs which they would forward to Quantum (much later renamed to QNX Software Systems) but nothing would happen. When I produced the decompiled sources it took me a single afternoon to fix the pending bugs and implement the feature requests.

The first step was to disassemble the binaries. As an OEM Softec had access to the .obj files so they could link in new drivers if needed, and those included the symbol tables giving me at least the function names. The C compiler didn't do any optimizations, so compiling a few sample programs was enough for me to then read through the assembler while typing in C and adding comments as I went along.

The version I worked on was called 1.1e even though versions 1.2 and 2.0 (which was just 1.2 plus networking) were available.

The overall idea for QNX (originally QUNIX) was solid, but early implementations were not so nice. In 1.1e it was possible to see that a lot had been fixed from earlier versions, but there still were a lot of problems. The File Manager was responsible for decoding executable files (the Task Manager should have done that instead), for example, and most of the functionality that should have been in the shell were hardwired into the Task Manager instead. This was greatly improved in version 1.2 which I looked at though I didn't decompile.

Even in version 1.1e, running QNX on a 256KB PC with floppies only was way nicer than other Unixes on much beefier machines. Each version was much better than the previous ones so by the 1990s the QNX people saw was a different experience than what was on those old machines.

You are right about how much harder higher clocks made things. PC mother boards got stuck at 33MHz for the longest time even though 50MHz processors were available. It took Intel coming out with the 486DX2 (50MHz inside the chip, 25MHz on the board) to get things moving again.

A key transition was moving from the 1 and 2 layer printed circuit boards of 1970s e cheap 1980s computers to 4 layers like in the IBM PC and Apple Macintosh. The difference a ground and power plane makes in the waveforms is simply amazing.

> Or, said another way, it was a teletype terminal which happened to have its own computer inside to talk to.

That is exactly what happened. A friend showed Woz how to access the Arpanet so he decided to build his own terminal. That was working before he started the Apple I, which simply added a built-in computer to the existing circuit.

In a similar way, the 1980 Decmate and the 1977 VT78 simply added a microprocessor version of the PDP-8 to an existing terminal (VT100 and VT52, respectively).

Among the issues that Cerebras had to overcome was how to connect tiles on a wafer where each tile has to be smaller than a reticle. In normal chips you have a gap on all sides where the diamond saw will cut the wafer into individual dies. Having wires cross that gap requires non standard processing. And the tiles themselves would still be limited to a single reticle (under 35mm on a side), so a multi-reticle M1 would not be easy to design.

The term "Brazil's cost" is about the legal overheads, which are much higher than anything due to corruption (which does, indeed, increase the cost of doing business).

The largest component is cascading taxes. There are some rules which allow you to get a discount on taxes of products you sell based on taxes of the components you bought, but in general each step in production and distribution will pay taxes on the incoming values including all previous taxes. That means that you look at a product in a store and think that the price includes 18% state taxes which doesn't sound so bad. But if you could trace it back through the supply chain all the way to mining the raw materials you would see that about 60% of the price is tax.

This, by the way, leads to the ironic situation where poor people pay way more taxes than rich ones even though the law is supposed to implement "progressive taxes". So the poor person is in the 0% income tax bracket but spends nearly everything they earn on stuff with hidden 60% taxes in them. The rich person is in the 35% income tax bracket but only a fraction of that income goes to products while much of their expenses have little to no taxes.

Other sources of "custo Brasil" are losses in transport due to bad infrastructure and crime, having to hire extra people to deal with complex regulations, costs due to delays and things like that.

Since the chip is meant for inference but not for training, in theory you only write to the Flash once or twice. In this case data retention is a more limiting factor than wear.

For digital storage the data can change quite a bit before a 1 becomes 0 or vice-versa, but for analog even a small change can be a problem. So I don't know if we can extrapolate the typical Flash memory data retention number to the expected aging for this device.

I only know a little about the Long Now Foundation so I could be getting it wrong, but I understood their goal was to help people think about problems beyond the short term. For example, why would anyone plant a tree if they will be long dead before that tree reaches its normal height?

Instead of just sitting around discussing vague ideas they thought it would be interesting to design and build something to showcase their ideas, so the "ten thousand year clock" was proposed. It is amazing how many problems you have to solve to build a clock that has even the slightest chance of still be running ten thousand years from now.

A side effect of the clock project was that some of the dates involved would have five digit years, so they thought using five digit years for current dates would be a good way of shocking people and exposing them to their ideas.

It is interesting to see such an extensive list that doesn't include Smalltalk or Forth. The lack of Pascal/Modula-2/Oberon is not a problem given Ada. Not having APL (or J or K) might not hurt if you get the needed ideas from Julia. Other languages such as Cobol (or the microcomputer equivalent such as dBase) most people can probably live without.

Here is a commercial bit addressed processor:

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

Indeed, the effort to port C and Unix to the Interdata forced C to evolve quite a bit (adding unions, typedefs and so on):

https://www.bell-labs.com/usr/dmr/www/portpap.html

The 68000 takes 4 clock cycles (minimum) to access memory and can read or write 2 bytes. At 8 MHz that means that the 68000 has a memory bandwidth of (8Mclocks/s/4clocks)x2bytes = 4Mbytes/s.

The 6502 takes 1 clock cycle (which might be stretched if needed) to access memory and can read or write 1 byte; At 2 MHz the 6502 in the BBC has a memory bandwidth of 2Mbytes/s.

So going from the 6502 to the 68000 would only get you twice the performance. But the 68000 takes many more clock cycles to handle an interrupt compared to the 6502 and since the BBC Micro was designed around interrupts instead of DMA this would eat up all the performance gain. This was true of the 16 bit micros from National, Zilog and Intel as well.

The ARM2 takes 1 clock cycle (which can be stretched if needed) to access memory and can read or write 4 bytes. In addition, it can tell memory if the next access will be random or if it will be at the address following the current one. DRAM has to slow down the processor for random accesses (a RAS cycle followed by a CAS cycle) but can work at full speed for sequential accesses (just CAS cycles). That means that sometimes the ARM2 runs at 4 MHz and sometimes at 8 MHz - supposing an average of 6 MHz is very reasonable. So we are talking about a bandwidth of 6Mx4 = 24Mbytes/s. That is 12 times faster than the 6502 and 6 times faster than the 68000. And the ARM2 has a normal interrupt that is very fast plus a fast interrupt that is instantaneous.

Note that in theory you need "2MHz" DRAMs for the BBC's 6502 or an 8MHz 68000. But in practice if you want to share the memory between video and the CPU you will need 4MHz DRAMs. Which is what the ARM2 also uses, but without sharing with video. The solution is to fetch the video in chunks using the sequential CAS-only mode, put it in a FIFO and then feed the video that instead of directly. Which is what the MEMC/VIDC companion chips for the ARM2 did. Now the video still slows down the processor, but doesn't hog 50% of the bandwidth.

The other popular architecture is the CPLD (complex programmable logic device) which grew out of the PALs (programmable array logic) of the late 1970s. Altera pioneered the CPLD and Xilinx the FPGA in the mid 1980s.

Until recently "FPGA" was used for tile based architectures and "CPLD" for macroblock architectures, but marketing has redefined the terms such that small FPGAs are now called CPLDs if they are non volatile (they are already configured when you turn them on).

Note that while the 1977 trio left their competitors in the dust, they were not the first prepackaged, preassembled personal computers on the market. But the makers of the Sphere, Compucolor II, Sol-20 and so on were terrible on the business side. While Apple was a VC backed startup and Tandy and Commodore were large companies as you pointed out. The rest became just footnotes in history which few people have ever heard of.

This one is written in Java:

https://github.com/hneemann/Digital

You can export your project as a Verilog file that can be used in the various FPGA tools.

It was the 1991 Cavallo Plan in Argentina that tied the local currency to the U.S. dollar:

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

The Real Plan in Brazil created a three month period with a combination of the old currency (Cruzeiros Novos) and a new virtual one (URV - Unidade Real de Valor) with an official daily exchange rate between them. This rate was selected to keep the URV at almost exactly 1 U.S. dollar but when both were replaced by a new actual currency (the Real), that was officially allowed to float relative to the dollar.

The real did initially get slightly valued relative to the dollar (an exchange rate of 1 R$ = 0.85 US$, for example) but floated slightly up and down until the end of 1998 when it suddenly jumped to 2 R$ = 1 US$ in order to block a huge wave of speculative money that was destroying economies around the world (having previously hit Russia, then the Asian Tigers).

The link says "$5,000,000,000 in 1964 is equivalent in purchasing power to about $44,968,064,516.13 today", which is $45 billion.

Considering that the entire revenue for IBM in 1964 was $3.2 billion (1964 money), spending $5 billion on a project (over several years) was certainly a "bet the company" move.

The 2008 RoarVM project allowed Squeak to run on a 56 core Tilera chip and was later ported to run on multiprocessor x86 machines:

https://stefan-marr.de/renaissance/

https://github.com/smarr/RoarVM

This was a research project so performance on a single core was poor compared to the official Squeak virtual machine, but it was an interesting exploration of the natural fit between objects/message passing and multiple cores.

Yes, the preliminary (1963) ASCII had an up arrow instead of the caret and a left arrow instead of the underline. DEC, Xerox and others built equipment around the 1963 draft and failed to change when the final version of ASCII came out. That is why when Pascal and Smalltalk came along later they used the "wrong" characters.

In the case of Smalltalk, it was Digitalk's "Methods" (the precursor of Smalltalk/V) that adopted := for assignment in place of the left arrow (though the IBM PC character set actually had one, just not with the same code as ASCII 1963) since all of its tutorials were aimed at Pascal programmers.

Simula I was a huge influence on Alan, as was Sketchpad (a parallel invention of object oriented programming). But Simula was a hybrid language like the later C++, so in the issue about message passing syntax Smalltalk had a certain impact.

Simula-67 introduced inheritance, which Smalltalk-72 and -74 didn't have. Many people see it as a key OOP feature, which Smalltalk-76 added.

Kristen Nygaard, who with Ole-Johan Dahl had created Simula, was one of the creators of the very pure Beta programming language.

https://en.wikipedia.org/wiki/BETA_(programming_language)

This took the message passing syntax in a very different direction:

    message -> receiver

Imagine that you have three friends helping you with a task. You might give them these instructions:

    Jack, clean the shelves.
    Helen, sort the reports.
    Lucy, turn on the printer.

You can see that the receiver of each message is the first thing in each line while the message follows it. That is the syntax of imperative expressions in English.

If your name is Kevin and you are the one sending on the messages, where is "Kevin" in the above text? And you sent three messages and yet there is not a single "send" command to be seen.

Here is a less trivial example:

     Jack hire a carpenter build cabinet store reports.

This is not valid English, but is a valid Smalltalk-72 expression. A variation which would have the same result is:

     ((Jack hire a carpenter) build cabinet) store reports.

The first message requests that Jack hire a carpenter. The result of the message is a carpenter who is not named by us, but which we can tell to build a cabinet. The result of this second message is a new cabinet, which we did not name either but which can be asked to store the reports.

So Smalltalk got its syntax from English and that inspired OOP languages that followed.

I am pretty sure it wasn't the case. I phoned Digitalk's Jim Anderson to try to negotiate a license to let me use their image with my 68000 based virtual machine (this was before Digitalk had any Mac versions) so I paid very close attention to the details of their licensing agreement.

Smalltalk/V was distributed as a nearly empty v.exe file plus a list of .dll files. As you developed your code it would get added to the v.exe so your stuff would always be clearly separated from Digitalk's. The .dlls were divided into two groups: basic system and development. The license allowed you to freely redistribute all files except for the development .dlls. If a client of yours wanted those for some reason they would have to buy their own Smalltalk V/DOS from Digitalk.

Except for the source to bytecode compiler, which was secret, the rest of the development system's sources were available. That meant that I didn't actually need Digitalk's permission to do what I wanted since I mostly wanted their sources (I had no idea how much Xerox would charge for the "real" Smalltalk but supposed it would be a lot more than what Digitalk might agree to). But I didn't want to take advantage of their not so well thought out license and upset them. Jim said he didn't think I would be able to port their stuff to the 68000 and didn't give permission for me to try, so I just went in a different direction.