- COFF - www.tuhs.org

Re: [TUHS] Re: machine code translation,as mental architecture models

by Dan Cross

On Wed, Jul 10, 2024 at 9:54 PM John R Levine <johnl(a)taugh.com> wrote: > On Wed, 10 Jul 2024, Dan Cross wrote: > > It's not clear to me why you suggest with such evident authority that > > Knuth was referring only to serialized instruction emulation and not > > something like JIT'ed code; true, he doesn't specify one way or the > > other, but I find it specious to conclude that that implies the > > technique wasn't already in use, or at least known. > > The code on pages 205 to 211 shows an instruction by instruction > interpreter. I assume Knuth knew about JIT compiling since Lisp systems > had been doing it since the 1960s, but that's not what this section of the > book is about. Sure. But we're trying to date the topic here; my point is that JITing was well known, and simulation was similarly well known; we know when work on those books started; it doesn't seem that odd to me that combining the two would be known around that time as well. > One of the later volumes of TAOCP was supposed to be about > compiling, but it seems unlikely he'll have time to write it. Yes; volumes 5, 6 and 7 are to cover parsing, languages, and compilers (more or less respectively). Sadly, I suspect you are right that it's unlikely he will have time to write them. > >> We've been discussing batch or JIT translation of code which gives > >> much better performance without a lot of hardware help. > > > > JIT'd performance of binary transliteration is certainly going to be > > _better_ than strict emulation, but it is unlikely to be _as good_ as > > native code. > > Well, sure, except in odd cases like the Vax compiler and reoptimizer > someone mentioned a few messages back. I think the point about the VAX compiler is that it's an actual compiler and that the VAX MACRO-32 _language_ is treated as a "high level" programming language, rather than as a macro assembly language. That's not doing binary->binary translation, that's doing source->binary compilation. It's just that, in this case, the source language happens to look like assembler for an obsolete computer. - Dan C.

9 months, 3 weeks

8
27
0 0

Re: [TUHS] Re: history of machine code translation,as mental architecture models

by Dan Cross

On Sat, Jul 13, 2024 at 1:35 PM John R Levine <johnl(a)taugh.com> wrote: > On Sat, 13 Jul 2024, Dan Cross wrote: > > Honeywell was doing it with their "Liberator" software on the > > Honeywell 200 computer in, at least, 1966: > > https://bitsavers.org/pdf/honeywell/series200/charlie_gibbs/012_Series_200_… > > (See the section on, "Conversion Compatibility."). Given that that > > document was published in February of 1966, it stands to reason work > > started on that earlier, in at least 1965 if not before ... > > Good thought. Now that you mention it, I recall that there were a lot of > Autocoder to X translators, where X was anything from another machine > to Cobol. Of course I can't find any of them now but they must have been > around the same time. > > R's, > John > > PS: For you young folks, Autocoder was the IBM 1401 assembler. There were > other Autocoders but that was by far the most popular because the 1401 was > the most popular computer of the late 1950s. Oops, it appears that I inadvertently forgot to Cc: COFF in my earlier reply to John. Mea culpa. For context, here's my complete earlier message; the TL;DR is that Honeywell was doing binary translation from the 1401 to the H-200 sometime in 1965 or earlier; possibly as early as 1963, according to some sources. -->BEGIN<-- Honeywell was doing it with their "Liberator" software on the Honeywell 200 computer in, at least, 1966: https://bitsavers.org/pdf/honeywell/series200/charlie_gibbs/012_Series_200_… (See the section on, "Conversion Compatibility."). Given that that document was published in February of 1966, it stands to reason work started on that earlier, in at least 1965 if not before (how much earlier is unclear). According to Wikipedia, that machine was introduced in late 1963; it's unclear whether the Liberator software was released at the same time, however. Ease of translation of IBM 1401 instructions appears to have been a design goal. At least some sources suggest that Liberator shipped with the H-200 in 1963 (https://ibm-1401.info/1401-Competition.html#UsingLib) It seemed like what Doug was describing earlier was still source->binary translation, using some clever macro packages. -->END<-- - Dan C.

9 months, 3 weeks

1
0
0 0

Re: system implementation languages e.g. BLISS (was: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?)

by Aron Insinga

(Let me try sending this again, now that I'm a member of the list.) Another example of operator-typing in BLISS, of more use in a kernel than floating point, is in the relational operators. For example, GTR (greater-than) for signed comparison, GTRU for unsigned comparison, and GTRA for address comparison (where the number of bits in an address is less than the number of bits in a machine word), etc. for the other 5 relations. On 7/9/24 13:18, Paul Winalski wrote: > expression-1<offset-expr, size-expr, padding-expr> > [...] padding-expr controls the value used to pad the high order > bits: if even, zero-padded, if odd, one-padded. > > I always wondered how this would work on the IBM S/360/370 > architecture. It is big-endian and bit 0 of a machine word is the > most significant bit, not the least significant as in DEC's architectures. Offset and Size taken as numbers of bits in a value (machine word), not bit numbers, works just fine for any architecture. The PDP-10 and other DEC architectures before the PDP-11 were word-addressed with bit 0 at the high-order end. The optional 3rd parameter is actually 0 for unsigned (zero) extension and 1 for signed (highest order bit in the extracted field) extension. I don't think signed extension is widely used, but it depends on the data structure you're using. When verifying that, I found something I did not remember, that in BLISS-16 and -32 (and I would guess also -64), but not -36 (the word-addressed PDP-10), one could declare 8-bit signed and unsigned data: OWN X: BYTE SIGNED, Y: BYTE; So the concepts of 'type' in BLISS, at least regarding data size and representation, can get a little complicated (not to be confused with COMPLEX :-) ). -------- An aside re: bit twiddling from CMU and hardware description languages: Note that the ISP/ISPL/ISPS machine description language(s) from books by Gordon Bell et al. used the following syntax for a bit or a bit field of a register: REG<BIT_NR> REG<HIGH_BIT_NR:LOW_BIT_NR> REG<BIT_NR,BIT_NR,...> (',...' is meta syntax.) Sign extension was handled by a unary operator because the data were all bit vectors, instead of values as in BLISS, so the width (in bits) of an expression was known. The DECSIM logic simulator inherited this syntax. Brackets were used for memory addresses, so you might have M[0]<0:2> for the first 4 bits of the first word in memory. I still find it the most clear syntax, but then it is what I used for many years. (Sorry, VHDL and Verilog, although you won due to the idea back in the day that internally-developed VLSI CAD software was to be kept internal.) - Aron

9 months, 3 weeks

2
1
0 0

Re: [TUHS] Re: machine code translation,as mental architecture models

by Dan Cross

[TUHS to Bcc:, +COFF] On Wed, Jul 10, 2024 at 5:26 PM John Levine <johnl(a)taugh.com> wrote: > It appears that Noel Chiappa <jnc(a)mercury.lcs.mit.edu> said: > > > From: Dan Cross > > > > > These techniques are rather old, and I think go back much further than > > > we're suggesting. Knuth mentions nested translations in TAOCP .. > > > suggesting the technique was well-known as early as the mid-1960s. > > Knuth was talking about simulating one machine on another, interpreting > one instruction at a time. As he notes, the performance is generally awful, > although IBM did microcode emulation of many of their second generation > machines on S/360 which all (for business reasons) ran faster than the > real machines. Unsurprisingly, you couldn't emulate a 7094 on anything > smaller than a 360/65. It's not clear to me why you suggest with such evident authority that Knuth was referring only to serialized instruction emulation and not something like JIT'ed code; true, he doesn't specify one way or the other, but I find it specious to conclude that that implies the technique wasn't already in use, or at least known. But certainly by then JIT'ing techniques for "interpreted" programming languages were known; it doesn't seem like a great leap to extend that to binary translation. Of course, that's speculation on my part, and I could certainly be wrong. > We've been discussing batch or JIT translation of code which gives > much better performance without a lot of hardware help. JIT'd performance of binary transliteration is certainly going to be _better_ than strict emulation, but it is unlikely to be _as good_ as native code. Indeed, this is still an active area of research; e.g., luajit; https://www.mattkeeter.com/blog/2022-10-04-ssra/ (disclaimer: Matt's a colleague of mine), etc. - Dan C.

9 months, 3 weeks

1
0
0 0

Re: [TUHS] Re: machine code translation,as mental architecture models

by segaloco

On Wednesday, July 10th, 2024 at 4:00 PM, John Levine <johnl(a)taugh.com> wrote: > It appears that Al Kossow aek(a)bitsavers.org said: > > > On 7/10/24 1:53 PM, Dan Cross wrote: > > > > > The idea of writing simulators for machines clearly dates to before > > > (or near) the beginning of TAOCP. > > > Sure, but the topic of interest here is compiling machine code from one > machine to another. You know like Rosetta does for x86 code running on > my Macbook (obUnix: whose OS is descended from FreeBSD and Mach and does > all the Posix stuff) which has an M2 ARM chip. > > We know that someone did it in 1967 from 709x to GE 635, which I agree > was quite a trick since really the only thing the two machines had in > common was a 36 bit word size. I was wondering if anyone did machine > code translation as opposed to instruction at a time simulation before that. > Attempting once again to COFF this thread as I am quite interested in the discussion of this sort of emulation/simulation matter outside of the confines of UNIX history as well. To add to the discussion, while not satisfying the question of "where did this sort of thing begin", the 3B20 was another machine that provided some means of emulating another architecture via microcode, although what I know about this is limited to discussions about emulating earlier ESS machines to support existing telecom switching programs. I've yet to find any literature suggesting this was ever used to emulate other general-purpose computers such as IBM, DEC, etc. but likewise no suggestion that it *couldn't* be used this way. - Matt G.

9 months, 3 weeks

1
0
0 0

Reminder: use the right list

by Warren Toomey

All, just a friendly reminder to use the TUHS mailing list for topics related to Unix, and to switch over to the COFF mailing list when the topic drifts away from Unix. I think a couple of the current threads ought to move over to the COFF list. Thanks! Warren

9 months, 3 weeks

1
0
0 0

Data types in operating systems

by Paul Winalski

I don't know of any OSes that use floating point. But the IBM operating systems for S/360/370 did use packed decimal instructions in a few places. This was an issue for the System/360 model 44. The model 44 was essentially a model 40 but with the (much faster) model 65's floating point hardware. It was intended as a reduced-cost high-performance technical computing machine for small research outfits. To keep the cost down, the model 44 lacked the packed decimal arithmetic instructions, which of course are not needed in HPTC. But that meant that off-the-shelf OS/360 would not run on the 44. It had its own OS called PS/44. IIRC VAX/VMS ran into similar issues when the microVAX architecture was adopted. To save on chip real estate, microVAX did not implement packed decimal, the complicated character string instructions, H-floating point, and some other exotica (such as CRC) in hardware. They were emulated by the OS. For performance reasons it behooved one to avoid those data types and instructions on later VAXen. I once traced a severe performance problem to a subroutine where there were only a few instructions that weren't generating emulator faults. The culprit was the oddball conversion semantics of PL/I, which caused what should have been D-float arithmetic to be done in 15-digit packed decimal. Once I fixed that the program ran 100 times faster. -Paul W.

9 months, 3 weeks

3
2
0 0

Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

by Paul Winalski

On Mon, Jul 8, 2024 at 9:04 PM Aron Insinga <aki(a)insinga.com> wrote: > I found it sad, but the newest versions of the BLISS compilers do not > support using it as an expression language. The section bridging pp > 978-979 (as published) of Brender's history is: > > "The expression language characteristic was often highly touted in the > early years of BLISS. While there is a certain conceptual elegance that > results, in practice this characteristic is not exploited much. > The most common applications use the if-then-else expression, for > example, in something like the maximum calculation illustrated in Figure 5. > Very occasionally there is some analogous use of a case expression. > Examples using loops (taking advantage of the value of leave), however, > tend not to work well on human factors grounds: the value computed tends to > be visually lost in the surrounding control constructs and too far removed > from where it will be used; an explicit assignment to a temporary variable > often seems to work better. > On balance, the expression characteristic of BLISS was not terribly > important." > > Ron Brender is correct. All of the software development groups at DEC had programming style guidelines and most of those frowned on the use of BLISS as an expression language. The issue is maintainability of the code. As Brender says, a human factors issue. > Another thing that I always liked (but is still there) is the ease of > accessing bit fields with V<FOO_OFFSET, FOO_SIZE> which was descended from > BLISS-10's use of the PDP-10 byte pointers. [Add a dot before V to get an > rvalue.] (Well, there was this logic simulator which really packed data > into bit fields of blocks representing gates, events, etc....) > > Indeed. BLISS is the best bit-banging language around. The field reference construct is a lot more straightforward than the and/or bit masks in most languages. In full the construct is: expression-1<offset-expr, size-expr, padding-expr> expression-1 is a BLISS value from which the bits are to be extracted. offset-expr is start of the field to be extracted (bit 0 being the low bit of the value) and size-expr is the number of bits to be extracted. The value of the whole mess is a BLISS value with the extracted field in the low-order bits. padding-expr controls the value used to pad the high order bits: if even, zero-padded, if odd, one-padded. I always wondered how this would work on the IBM S/360/370 architecture. It is big-endian and bit 0 of a machine word is the most significant bit, not the least significant as in DEC's architectures. -Paul W.

9 months, 3 weeks

1
0
0 0

Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

by Paul Winalski

[redirecting this to COFF] On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki(a)insinga.com> wrote: > > When DEC chose an implementation language, they knew about C but it had > not yet escaped from Bell Labs. PL/I was considered, but there were > questions of whether or not it would be suitable for a minicomputer. On > the other hand, by choosing BLISS, DEC could start with the BLISS-11 > cross compiler running on the PDP-10, which is described in > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler > BLISS-11 > <https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_CompilerBLISS-11> > and DEC's Common BLISS had changes necessitated by different > word lengths and architectures, including different routine linkages > such as INTERRUPT, access to machine-specific operations such as INSQTI, > and multiple-precision floating point operations using builtin functions > which used the addresses of data instead of the values. > > In order to port VMS to new architectures, DEC/HP/VSI retargeted and > ported the BLISS compilers to new architectures. > > There have in general been two approaches to achieving language portability (machine independence). One of them is to provide only abstract data types and operations on them and to completely hide the machine implementation. PL/I and especially Ada use this approach. BLISS does the exact opposite. It takes the least common denominator. All machine architectures have machine words and ways to pick them apart. BLISS has only one data type--the word. It provides a few simple arithmetic and logical operations and also syntax for operating on contiguous sets of bits within a word. More complicated things such as floating point are done by what look like routine calls but are actually implemented in the compiler. BLISS is also a true, full-blown expression language. Statement constructs such as if/then/else have a value and can be used in expressions. In C terminology, everything in BLISS is a lvalue. A semicolon terminates an expression and throws its value away. BLISS is also unusual in that it has an explicit fetch operator, the dot (.). The assignment expression (=) has the semantics "evaluate the expression to the right of the equal sign and then store that value in the location specified by the expression to the left of the equal sign". Supposing that a and b are identifiers for memory locations, the expression: a = b; means "place b (the address of a memory location) at the location given by a (also a memory location)". This is the equivalent of: a = &b; in C. To get C's version of "a = b;" in BLISS you need an explicit fetch operator: a = .b; Forgetting to use the fetch operator is probably the most frequent error made by new BLISS programmers familiar with more conventional languages. DEC used four dialects of BLISS as their primary software development language: BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers indicating the BLISS word size in bits. BLISS-16 targeted the PDP-11 and BLISS-36 the PDP-10. DEC did implementations of BLISS-32 for VAX, MIPS, and x86. BLISS-64 was targeted to both Alpha and Itanium. VSI may have a version of BLISS-64 that generates x86-64 code. -Paul W.

9 months, 4 weeks

2
1
0 0

Dan Murphy [Tenex Designer] Quote

by Clem Cole

I moved this to COFF since it's a TWENEX topic. Chet Ramsey pointed folks at a wonderful set of memories from Dan Murphy WRT to the development of TENEX and later become TOPS-20. But one comment caught me as particularly wise and should be understood and digested by all: *"... a complex, complicated design for some facility in a software or hardware product is usually not an indication of great skill and maturity on the part of the designer. Rather, it is typically evidence of lack of maturity, lack of insight, lack of understanding of the costs of complexity, and failure to see the problem in its larger context."* ᐧ

10 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF