Bill Gunshannon via cctalk wrote on Mon, 10 Apr 2017 20:59:40 +0000 This shared most chips with the DEC LSI-11 but used different microcode. I created this list for one of my talks: Historical Language Specific Architectures: - Algol: English Electric KDF9, Burroughs B5000 - APL: Philip Abrams' machine - Pascal: Western Digital Microengine - Modula-2: Lilith - extended Ada: Intel iAPX432 - Lisp: Symbolics, Lisp Machine Inc., Texas Instruments, Xerox D Machines - Forth: Novix, Harris RTX-2000, MISC MC17, WISC CPU/16, SC32, MuP21, MSL16, Ignite, i21, F21, E16, MARC4, QSP16, TF2216, Steamer16, MicroCore,J1, SC20, F18 GA144 - Java: picoJava, aj102, Cjip, Komodo, FemtoJava, ARM Jazelle,JOP, SHAP, MAJIC - Smalltalk: Xerox D Machines, Katana32, Swamp, AI32, SOAR, COM, Rekursive, Mushroom, J-Machine I expect this list is not complete. Note that I don't include computers created for a specific language using a conventional processor, like the APL computers MCM/70, IBM 5100 and Ampere WS-1. Some architectures that are considered general purpose have included features to support specific languages. The original 8086 was good at running Pascal, but pretty bad at C, for examle (this was fixed in the 386). The National 32016 tried to support Modula-2 (and Ada) which forced the 68020 to add matching features, which then were dropped from the 68030 as it became obvious that C had won the language wars of the 1980s. About the original question, since the Burroughs architecture was eventually implemented as a microprocessor you can say that this was designed to run Algol: http://www.cpushack.com/2015/04/18/the-forgotten-ones-unisys-scamp-d-mai nframe/ -- Jecel

Chuck Guzis via cctalk wrote on Date: Mon, 10 Apr 2017 15:21:08 -0700 I just found an academic Pascal microprocessor from 1980 called EM-1 and described all the way to the chip layout level: http://authors.library.caltech.edu/27046/1/TR_2883.pdf I talked about the problem with far pointers and C in the post about the iAPX 432. The 64KB segments in the 8086 were not a problem for Pascal (or Smalltalk, as shown by the Xerox PARC Notetaker computer) because each heap object and each proceedure can live in a different segment to take advantage of the whole memory. A single object (like an array) can't be split into multiple segments which limits us to small objects (this is not a problem for Smalltalk which can completely hide such splits as shown in the Mushroom computer). One big difference between Pascal and C is that while C seems to have nested lexical scoped like Algol at first glance (and indeed it is often list as being part of the "Algol family") it really doesn't. An object either lives in the heap or is in the local stack frame. You can declare new variables inside { ... } and they will shadow variables with the same name declared outside of these brackets but this has no effect on the runtime structures. Pascal, on the other hand, allows proceedures to be declared inside other proceedures and these nested scopes can access stuff declared in the more external scopes. This requires some runtime structures that can be awkward to implement in many processor architectures. An expression like: x := y; might generate quite a bit of code if "x" was declared one level up and "y" was declared three levels up. But on the 8086 we could have pointers to the frames of the various lexical levels saved at the start of the current frame just like the "display registers" in the Burroughs B5000. We could have something like: mov di,[bp-2*3] ; lexical level 3 mov ax,[di-20] ; y mov di,[bp-2*1] ; lexical level 1 mov [di-8],ax ; x Filling up those pointers on each proceedure entry can take some time so a popular alternative for when nested references were not too common was to have a linked list of runtime frames and code like: mov di,[bp-2] ; lexical level 1 mov di,[di-2] ; lexical level 2 mov di,[di-2] ; lexical level 3 mov ax,[di-20] ; y mov di,[bp-2] ; lexical level 1 mov [di-8],ax ; x Being able to directly address constant offsets from the base pointer and offsets from the result of that greatly reduces the number of instructions needed to support lexical scoping in Pascal. For C, constant offsets from a pointer are great for getting at the elements of structs, so this is a nice thing to have in any case and most RISCs implement this. -- Jecel p.s.: I haven't programmed in x86 assembly since 1987 so don't trust the above code fragments

On 04/10/2017 04:47 PM, Jecel Assumpcao Jr. via cctalk wrote: Oh, heck, I pointed out the problems with segment-offset addressing before the 8086 was released on silicon to Intel applications engineers. They didn't seem to think it was a big deal. I even asked for an "add to far" instruction that would get rid of the nasty bit manipulation, but to no avail. But for tiny, small and compact memory models, the 8086 is just fine. Speculatively, I don't think that the 8086 was initially considered as a minicomputer-type processor, but more of an extension of the x80 architecture to serve the embedded world. No privileged mode, strange segment/offset addressing, etc. I suspect that at some point, Intel had its big-system hopes pinned on the iA432 chipset. The fiction of automatic translation from 8080/85 code was just that. I recall that "Fast Eddie", our local sales rep made the mistake of telling a tall one that Intel's assembly-language translator produced smaller code that ran faster than the x80 version. I called him on it and gave him a sample program that ran under ISIS-II and told him to do his best. It was a floating-point package, with test data. Straight code; no fancy macros. I probably still have the original code somewhere. So, we went down to the local sales office in Santa Clara where there was an MDS all set up, complete with hard drive and the 80-to-86 translator. I cautioned the sales engineer that the code did a lot of tricky stuff with flags, so any translation would have to be very accurate. The program went in (it was about 10 AM) and the MDS just ground and ground... 12:30 came around and we were treated to lunch while the translator worked on the miserable 3000 lines of 8080 assembly. Back goodbyes and told him to contact us when they finally got it to work. Two weeks passed and Fast Eddie called to say that they had finally got the translation done (after some tweaking of the translator). The result was that the translated code was nearly twice as large as the x80 code and, while the program executed, it gave the wrong answers (we didn't tell them what the answers should be as part of the test). I was advocating the very new Motorola 68K chip and had even produced a (wirewrap) prototype CPU board that ran enough code to get to the "Hello world" stage. Unfortunately, Bill Davidow was on our BOD and he said in no uncertain terms that it would be a cold day in Hell if one of the companies he shepherded used a competitor's CPU. So we eventually wound up using the 80186, and added a spot for the 80286 on the CPU board. We got it all working, but it was a long slog because we were using prerelease silicon and a bug could stop us dead for two weeks or more while we awaited the next stepping. --Chuck

It was thus said that the Great Jecel Assumpcao Jr. via cctalk once stated: There's nothing here that makes it a problem for C. You will end up with using large pointers (segment, offset) but that would be the same for your hypothetical Pascal compiler. It does. The same is true for Pascal or any other language in the "Algol" family. Yes. You cannot do this in C because unlike Pascal (and I support others in the Algol family), C allows you to pass functions to other functions via function pointers. Pascal does not allow this [1], because of exactly this reason---external scopes. [2] It becomes more difficult to support. Not impossible, just real ugly (and most likely a special case). Yes, and so can the VAX, 6809, 68000, MIPS, SPARC. It might be a bit more convenient to do on the Intel x86 line, but almost no compiler I know of actually *use* the x86 instructions dedicated for this feature (they're too slow). Ah yes, the ENTER instruction. You mean: mov di,[bp] ; up one level mov di,[di] ; up two levels mov di,[di] ; up three levels mov ax,[di - 20],ax mov di,[bp] ; up one level mov [di - 8],ax -spc [1] Standard Pascal. I'm willing to conceed a system might have a Pascal with non-standard extensions that allow function pointers, but then it isn't standard Pascal, is it? [2] GCC does allow you to declare nested functions in C, but again, that's a non-standard C extension.

On Tue, Apr 11, 2017 at 7:49 AM, Jecel Assumpcao Jr. via cctalk <cctalk at classiccmp.org> wrote: It is worth remembering the SCAMP MCM also supported the IBM 370 for the Unisys System-80/7E platform (running OS/3). However the SCAMP was implemented it could handle two quite different machine architectures.

It was thus said that the Great Eric Smith via cctalk once stated: What about C made it difficult for the 432 to run? -spc (Curious here, as some aspects of the 432 made their way to the 286 and we all know what happened to that architecture ... )

It was thus said that the Great Jecel Assumpcao Jr. via cctalk once stated: Just because a ton of C code was written with that assumption doesn't make it actually true. A lot of C code assumes a byte-addressable, two's compliment architecture but C (technically Standard C) doesn't require either and goes out of its way to warn programmers *not* to make such assumptions. The C Standard is very careful to note what is and isn't allowed with respect to memory and much of what is done is technically illegal and anything can happen. Given: p1 = malloc(10); p2 = malloc(65536); There is no legal way to increment *or* decrement one to get to the other. It's not even guarenteed that p2 > p1. This is an issue, but mostly with K&R C (which had even less type checking than ANSI C). These days a compiler will warn if you try to pass a function even with *no* cranking of the warning levels. Yes, C has issues, but please try not to make ones up for modern C. But if the point was, back in the day (1982) that this *was* an issue, then yes, I would agree (to a point). But I would bet that had the 432 been successful, a C compiler would have been produced for it. "Far" pointers exist for MS-DOS to support mixed memory-model programming, where library A wants object larger than 64K while library B doesn't care either way. Yes it's a mess but that's pragmatism for you. But there's still code out there with such remnents, like zlib. For example: ZEXTERN int ZEXPORT inflateBackInit OF((z_stream FAR *strm, int windowBits, unsigned char FAR *window)); ZEXTERN, XEXPORT, OF and FAR exist to support different C compilers over the ages. And of those, XEXTERN and XEXPORT are for Windows, FAR for MS-DOS (see a pattern here?) and OF for pre-ANSI C compilers. -spc

It was thus said that the Great Jecel Assumpcao Jr. via cctalk once stated: I can relate. I have the code to Viola [1] and it no longer compiles cleanly [2]. I have cleaned up the code enough to get it to produce an executable, but man ... the code ... it *barely* runs on a 32-bit system and immeidately crashes on a 64-bit system, mainly due to the deeply baked in assumption that sizeof(int) == sizeof(long) == sizeof(char *) == sizeof(void *) which is not always the case (even C says as much). But it was written in a time of flux, just after C was standardized and not everyone had an ANSI-C compiler. Yeah, I recently wrote code that used ENTER (works on both 32-bit and 64-bit x86 CPUs) just to figure out how it works. I never found the description clear and NONE of the examples actually used it for nested stack frames (sigh). -spc [1] http://www.viola.org/ [2] Conflicting types for malloc() and fprintf(), and use of an obsolete header.

On Mon, Apr 10, 2017 at 3:39 PM, Sean Conner <spc at conman.org> wrote: The iAPX 432 was a capability based architecture; the only kind of pointer supported by the hardware was an Access Descriptor, which is a pointer to an object (or a refinement, which is a subset of an object). There is no efficient way to do any kind of pointer arithmetic, even with refinements. In the Release 1 and 2 architectures, objects were either Access Objects, which could contain Access Descriptors (pointers to objects), or Data Objects, whcih could NOT contain Access Descriptors. As a result, architectural objects were often used in pairs, with the Access Object having an Access Descriptor at a specific offset (generally 0) pointing to the corresponding Data Object. In the Release 3 architecture, a single object could have both an Access Part and a Data Part, with basically the same restriction: the Access Part can only store Access Descriptors, and the Data Part can NOT store Access Descriptors. As a consequence, a C pointer to a structure containing both pointer and non-pointer data would have to be represented as a composite of: 1) an Access Descriptor to the containing object 2) an offset into the data object or data part, for the non-pointer data, and the non-Access-Descriptor portion of any pointers 3) an offset into the access object or access part, for the Access Descriptor portion of any pointers The architecture provides no assistance for managing this sort of pointer; the compiler would just have to emit all the necessary code. However, C requires that it be possible to cast other data types into pointers. The 432 can easily enough let you read an access descriptor as data, but it will not allow you to write data to an access descriptor. That will raise an exception. It would take really awful hacks in the operating system to subvert that, and would be insanely slow. (On a machine that was already quite slow under normal conditions.) You can't even cast an Access Descriptor (which occupies 32 bits of memory) to uint32_t, then cast it back unmodified, e.g., to store a pointer into an intptr_t then put it back in a pointer. It would almost certainly be more efficient to implement C on the 432 by simply allocating a single large array of bytes as the memory for the C world, and implementing pointers only as offsets within that C world. This would preclude all access from C code to normal 432 objects, except by calling native libraries through hand-written glue. It would effectively be halfway to an abstract C machine; the compiler could emit a subset of normal 432 machine instructions that operate on the data. Note that the 432 segment size is limited to 64KB. Accessing an array larger than that, such as the proposed C world, is expensive. You have to have an array of access descriptors to data objects of 64KB (or some other power of 2) each. Release 1 and 2 provide no architectural support for it, so the machine code would have to take C virtual addresses and split them into the object index and offset. Release 3 provides an instruction for indexing a large array in this fashion; IIRC the individual data objects comprising the array are 2KB each. -spc (Curious here, as some aspects of the 432 made their way to the 286 The only siginificant aspect of the 432 that made it into the 286 was the use of 64KB segments, and that had already been done (badly) in the 8086. The 432 architects went on to design a RISC processor that eliminated most of the drawbacks of the 432, but still supported object-oriented addressing, type safety, and memory safety, but using 33-bit word with one bit being the tag to differentiate Access Descriptors from data. This became the BiiN machine, which was unsuccessful. With the tag bit and object-oriented instructions removed, it became the i960; the tag bit and object-oriented instructions were later offered as the i960MX. The military used the i960MX, but it is unclear whether they actually made use of the tagging. Eric

Back then it would have seemed a reasonable assumption that high level, strongly typed, languages would continue to flourish. If you assume Algol or Pascal or Ada, a machine like the 432 (or like the Burroughs 5500 and its descendants) makes perfect sense. I don't think this is exactly a question of RISC vs. CISC, but rather a question of how you believe addressing is done. For example, the EL-X8 is a one address machine with a regular instruction layout, which makes it somewhat RISC like in structure. But it has addressing modes clearly designed for efficient handling of block structured recursive languages like Algol. paul

On Apr 11, 2017 11:29 AM, "Chuck Guzis via cctalk" <cctalk at classiccmp.org> wrote: Oh, there's a very simple answer to that. They didn't! Early in the 8800/432 development (which started in 1975), Intel was developing their own language for it, generally in the Algol family. It's possible that they intended to support other languages, but Fortran definitely would have been a poor fit. When Ada came along, they decided that it was a reasonably good fit, and with the DoD pushing Ada, that would be an easier sell to customers than a proprietary language. Intel marketing basically claimed that the 432 was designed for Ada, though that wasn't really the case. The only two programming languages Intel supported on the 432 were: 1) Ada, using a cross-compiler written in Pascal and hosted on a VAX, to run on "real" 432 systems such as the 432/670 2) Object Programming Language (OPL), a Smalltalk dialect based on Rosetta Smalltalk, which only ran on the 432/100 demo board, a Multibus board inserted in a slot of an Intel MDS decelopment system. Late in the 432 timeline there was an unsupported port of XPL, but it did not generate native code. Apparently there was little concern for either Fortran or COBOL, the most widely used programming languages at the time.

Chuck Guzis via cctalk wrote on Tue, 11 Apr 2017 09:37:27 -0700 I consider the heart of any modern high performance CPU to be a dataflow architecture (described as an "out of order execution engine") with a hardware to translate the macrocode (CISC or RISC) to the dataflow graph and tokens on the fly. -- Jecel

Chuck Guzis via cctalk wrote on Tue, 11 Apr 2017 18:05:01 -0700 I have never seen anybody else, including people whose research in the late 1980s was dataflow architectures, do so either. But I see an engine with 24 "in flight" instructions plus all the register renaming circuits and it sure looks the same to me. I was not aware that there had been any out of order implementations after the IBM ACS until the second half of the 1990s. Given Cray's passion for simplicity, I would not expect any of his designs to use o-o-o (specially one as early as the CDC 6600). That is the one I am most familiar with, along with the Manchester Dataflow Machine and the MIT Tagged Token machine. An interesting modern dataflow architecture is the TRIPS: https://en.wikipedia.org/wiki/TRIPS_architecture -- Jecel

Chuck Guzis wrote: There are actually quite a few Forth processors. Charles Moore himself designed half a dozen or so. The RTX-2000 series is a descentant of his Novix chip. Check out GreenArrays for his latest work. There are also some FPGA designs out there. The J1 seems somewhat popular.