From clemc at ccc.com Thu Jul 4 03:58:58 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jul 2024 13:58:58 -0400 Subject: [COFF] Dan Murphy [Tenex Designer] Quote Message-ID: 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."* ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Thu Jul 4 04:19:29 2024 From: coff at tuhs.org (Chet Ramey via COFF) Date: Wed, 3 Jul 2024 14:19:29 -0400 Subject: [COFF] Dan Murphy [Tenex Designer] Quote In-Reply-To: References: Message-ID: <618fb8ac-33c9-4745-bb07-f6c8f7bb6b63@case.edu> On 7/3/24 1:58 PM, Clem Cole wrote: > I moved this to COFF since it's a TWENEX topic.  Chet Ramsey pointed folks It's Ramey. ;-) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From clemc at ccc.com Thu Jul 4 04:25:42 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jul 2024 14:25:42 -0400 Subject: [COFF] Dan Murphy [Tenex Designer] Quote In-Reply-To: <618fb8ac-33c9-4745-bb07-f6c8f7bb6b63@case.edu> References: <618fb8ac-33c9-4745-bb07-f6c8f7bb6b63@case.edu> Message-ID: Tell Autocorrect/Grammerly -- sorry about that. Sigh... ᐧ ᐧ On Wed, Jul 3, 2024 at 2:19 PM Chet Ramey wrote: > On 7/3/24 1:58 PM, Clem Cole wrote: > > I moved this to COFF since it's a TWENEX topic. Chet Ramsey pointed > folks > > It's Ramey. ;-) > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jul 9 08:14:07 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 8 Jul 2024 18:14:07 -0400 Subject: [COFF] [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: [redirecting this to COFF] On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga 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 > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 9 09:18:11 2024 From: coff at tuhs.org (segaloco via COFF) Date: Mon, 08 Jul 2024 23:18:11 +0000 Subject: [COFF] [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: On Monday, July 8th, 2024 at 3:14 PM, Paul Winalski wrote: > [redirecting this to COFF] > > On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga 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_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. On the subject of "closer to the machine" non-assembly languages, were there any noteworthy languages that people actually wrote in (as opposed to intermediates used 99% of the time inside the machinery of compilers) that exposed up specific-but-widely-available machine features as extensions? Where I'm going with this is for instance clearing a condition code in a status register. Most machines with a status register give you a means to either directly interact with it (e.g. 68k ccr) or use individual operations to twiddle the bits (e.g. 6502 sec/clc). Say I wanted, for whatever reason, in a language higher than assembly, have the ability to clear the CPUs idea of a carry bit. Yeah, not every CPU may have an accessible representation of carry, so doing this in a language would certainly reduce the portability, but theoretically could be abstracted just enough to allow one single "clear carry" abstract operation to map to and'ing the right bitmask on 68k, running a clc on a 6502, and so on. Granted, in C and other languages, this is usually achieved with inline assembly or callouts to some sort of assembly machdep type file, but what I'm wondering is if any language used predominantly by human programmers has ever tried to offer these sorts of things as first-class abstractions. The same could be said about privilege-related things, such as providing in the language an abstract concept of exception/interrupt handling that steps between privilege levels. Yeah, different CPUs may do that sort of thing quite differently, but if the preponderance of machines you're targeting with some bit of code implement a two-tier supervisor/user privilege model, being able to "write-once-run-anywhere" for this two-level model without knowing the particulars of the CPU's specific privilege escalation/deescalation mechanism could be helpful. I do concede though that most folks working at that level *do* want to intimately provide their own machine-language handlers for that sort of thing for efficiency reasons, but if even just for prototyping, I could see a rough abstraction of things like status bit changes and interrupt/exception interaction being helpful at times. - Matt G. From paul.winalski at gmail.com Wed Jul 10 03:18:25 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 9 Jul 2024 13:18:25 -0400 Subject: [COFF] [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: On Mon, Jul 8, 2024 at 9:04 PM Aron Insinga 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 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Jul 10 03:35:12 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 9 Jul 2024 13:35:12 -0400 Subject: [COFF] Data types in operating systems In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jul 10 03:46:23 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 9 Jul 2024 13:46:23 -0400 Subject: [COFF] Data types in operating systems In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski wrote: > I don't know of any OSes that use floating point. I've seen it. Not for numeric computations, primarily, but for fast data transfer a la `memcpy` using SIMD instructions in the FPU. In the BSD kernels circa 4.3, load average calculation used a modicum of FP (multiplication as double's). Oh, and I've seen some amount of FP hardware used for computing checksums. Of course, the OS must save and restore the state of the FPU on a context switch, but that's rather obviously not what you meant; I only mention it for completeness. > 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. It never ceases to amaze me how seemingly minor details can have such outsized impact. - Dan C. From steffen at sdaoden.eu Wed Jul 10 08:20:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 10 Jul 2024 00:20:00 +0200 Subject: [COFF] Data types in operating systems In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: <20240709222000.GYGgLzv2@steffen%sdaoden.eu> Dan Cross wrote in : |On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski \ |wrote: |> I don't know of any OSes that use floating point. | |I've seen it. Not for numeric computations, primarily, but for fast |data transfer a la `memcpy` using SIMD instructions in the FPU. In Yes, .. not SIMD (what i know), but using the floating-point stack on x86 one could get dramatic performance boosts for bzero(), and for the copies etc. (Ie, by fildq loading for example 64 bytes into the stack, then fistpq saving it to the destination. On Athlon this was very fast even on non-aligned pointers.) And i think the MMX extension registers effectively "were" the FP stack. |the BSD kernels circa 4.3, load average calculation used a modicum of |FP (multiplication as double's). Oh, and I've seen some amount of FP |hardware used for computing checksums. | |Of course, the OS must save and restore the state of the FPU on a |context switch, but that's rather obviously not what you meant; I only |mention it for completeness. .. I am an integer fan. The hardware front brought so many floating-point improvements that today i think they are "as fast" as integer on x86, multiplication and division, etc. But i hated sox ("the Swiss Army knife of audio manipulation") for using floating point internally, when i come in with 16-bit audio data; i keep the all-integer tremor library for Ogg Vorbis audio, for some future day; noone used it, i still do not understand why. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From coff at tuhs.org Thu Jul 11 07:57:44 2024 From: coff at tuhs.org (Warren Toomey via COFF) Date: Thu, 11 Jul 2024 07:57:44 +1000 Subject: [COFF] Reminder: use the right list Message-ID: 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 From coff at tuhs.org Thu Jul 11 09:14:52 2024 From: coff at tuhs.org (segaloco via COFF) Date: Wed, 10 Jul 2024 23:14:52 +0000 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: <20240710230010.D2D968F5DEE4@ary.qy> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <011a1e2a-6a73-ceaa-2b9c-9ca43daf41e7@bitsavers.org> <20240710230010.D2D968F5DEE4@ary.qy> Message-ID: On Wednesday, July 10th, 2024 at 4:00 PM, John Levine wrote: > It appears that Al Kossow aek at 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. From crossd at gmail.com Thu Jul 11 11:29:58 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Jul 2024 21:29:58 -0400 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: <20240710212641.E24548F5C32C@ary.qy> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> Message-ID: [TUHS to Bcc:, +COFF] On Wed, Jul 10, 2024 at 5:26 PM John Levine wrote: > It appears that Noel Chiappa 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. From crossd at gmail.com Thu Jul 11 12:05:27 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Jul 2024 22:05:27 -0400 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: <18977302-8934-ec96-9154-b3c53824e506@taugh.com> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> Message-ID: On Wed, Jul 10, 2024 at 9:54 PM John R Levine 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.