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. From paul.winalski at gmail.com Fri Jul 12 02:50:37 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 11 Jul 2024 12:50:37 -0400 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: 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 10:12 PM Dan Cross wrote: > 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. > Yes, that was precisely my point, and thank you for stating it more clearly and concisely than I did. The VAX MACRO compiler takes in VAX assembly source code, not binary VAX instructions. The discrete transistor -> integrated circuit transition (2nd generation-> 3rd generation) eventually resulted in enough of a speedup that microcode implementations of instruction sets such as System/360 offered acceptable performance at a low manufacturing cost. IIRC System/360 models 75 and up were done completely in hardware--no microcode. S/360 models 67 and down were microcoded. The lowest end S/360, the model 25, was actually a 16-bit machine. All the S/360s from the 65 and down had microcoded emulators for 2nd generation IBM architectures such as the 1400. The emulators usually ran faster than the real hardware. The emulators were there to accommodate data centers that had lost their source code for mission critical applications. There was also translation software available that would translate 2nd generation machine code into COBOL. I remember their ads appearing weekly in ComputerWorld. It showed a data center manager smacking his forehead. The headline of the ad read, "1400 emulation? In your 19xx budget?" I never had personal experience with the translator, but I'm told that the resulting COBOL was hard to maintain. Another example of using instruction set emulation was the IBM 5100 Portable Computer. Released in 1975, this was a desktop-sized machine with an attached keyboard and small CRT screen. One interacted with it in either APL or BASIC, the language selectable by a toggle switch. 64K of memory was available to the user. Internally the machine had a CPU codenamed Palm that was used in many of IBM's peripheral controllers. The hardware had two 64K banks of ROM and one 64K bank of RAM. One of the ROM banks held the BASIC interpreter and the other bank the APL interpreter. The front panel toggle switch selected which ROM bank was in use. The BASIC interpreter was implemented in native Palm code. But the APL interpreter was APL\360, in S/360 machine code. There was a S/360 instruction set emulator written in Palm code that interpreted the APL\360 interpreter. This sort of situation delivers horrible performance. During grad school I interned for a few years at IBM's Cambridge Scientific Center (CSC) in Cambridge, MA, the birthplace of CP-67, the virtual machine software system, and CMS (Cambridge Monitor System), an interactive OS that ran in CP-67 virtual machines. The CSC folks got hold of a 5100 and were fascinated in its S/360 instruction set emulation facility. The first versions of CMS ran in less than 64K on a S/360 model 40. CSC had a project to take modern CMS, put it on a bit of a diet, and then run it on the 5100, thus creating an interactive, desktop S/370. Project programming was done on a large S/370 mainframe. The problem was getting the code onto the 5100. They eventually wrote an OS/VS link editor in APL that ran on the 5100 and linked OS/VS object files into executable images stored on the 5100's floppy disk. They wrote a APL shared variable module called delta-S360 that caused the Palm processor's S/360 emulator to stop emulating the APL interpreter and instead emulate instructions loaded into an APL variable passed as a parameter to delta-S360. The APL link editor ran as slow as death. It processed one object file card image every 10 seconds or so and took hours to link a program. I was given the task of writing an OS/360 link editor that could run standalone on the 5100's S/360 emulator. It was invoked from the APL interpreter by a delta-S360 call. With the APL interpreter out of the picture, my link editor ran the floppy disk as fast as it could go and reduced link time from hours to minutes. Knuth was right about multiple levels of emulation/interpretaton. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jul 12 06:32:05 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 12 Jul 2024 06:32:05 +1000 (EST) Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> Message-ID: On Thu, 11 Jul 2024, Paul Winalski wrote: > The lowest end S/360, the model 25, was actually a 16-bit machine. Wouldn't that be the /20? 16-bit, 8 registers, no FP (but did have a HALT instruction), etc... -- Dave From johnl at taugh.com Sat Jul 13 02:23:44 2024 From: johnl at taugh.com (John R Levine) Date: 12 Jul 2024 12:23:44 -0400 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> Message-ID: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> On Thu, 11 Jul 2024, Paul Winalski wrote: > Yes, that was precisely my point, and thank you for stating it more clearly > and concisely than I did. The VAX MACRO compiler takes in VAX assembly > source code, not binary VAX instructions. Does anyone know how extensively they used the macro facilities? You can write much higher level stuff as macros than as single instructions, which makes it a lot easier to do efficient translation. For example, on OS/360 you'd write a GET macro to retrieve the next record (or a pointer to it) from a file, which was a lot easier to figure out than the control blocks and subroutine calls the macros expanded into. > were done completely in hardware--no microcode. S/360 models 67 and down > were microcoded. The lowest end S/360, the model 25, was actually a 16-bit > machine. The /25 and /30 were 8 bits internally and as slow as you would expect, but were still full implementations of S/360. IBM sold a lot of them. The /40 was 16 bits, /50 32 bits, and /65 64 bits. The later /85 was roughly a /65 reimplemented in faster logic with a cache and 128 bit memory, making it as fast as the more expensive /91 for programs that didn't use a lot of floating point. The /85 was microcoded and could emulate a 7094. All the S/360s from the 65 and down had microcoded emulators for > 2nd generation IBM architectures such as the 1400. The emulators usually > ran faster than the real hardware. They always ran faster, company policy. That's why you needed a 360/65 to emulate a 7094. > The emulators were there to accommodate data centers that had lost their > source code for mission critical applications. Partly that, more that the emulators allowed the customers to spread the conversion work out partly before they got the new machine, partly after. Remember that the new machine was faster and had better peripherals. Since it was built with more modern components it may well have been cheaper to rent. > Knuth was right about multiple levels of emulation/interpretaton. The 5100 was indeed a marvel, but it was a very slow one. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From johnl at taugh.com Sat Jul 13 02:23:44 2024 From: johnl at taugh.com (John R Levine) Date: 12 Jul 2024 12:23:44 -0400 Subject: [COFF] [TUHS] Re: machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> Message-ID: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> On Thu, 11 Jul 2024, Paul Winalski wrote: > Yes, that was precisely my point, and thank you for stating it more clearly > and concisely than I did. The VAX MACRO compiler takes in VAX assembly > source code, not binary VAX instructions. Does anyone know how extensively they used the macro facilities? You can write much higher level stuff as macros than as single instructions, which makes it a lot easier to do efficient translation. For example, on OS/360 you'd write a GET macro to retrieve the next record (or a pointer to it) from a file, which was a lot easier to figure out than the control blocks and subroutine calls the macros expanded into. > were done completely in hardware--no microcode. S/360 models 67 and down > were microcoded. The lowest end S/360, the model 25, was actually a 16-bit > machine. The /25 and /30 were 8 bits internally and as slow as you would expect, but were still full implementations of S/360. IBM sold a lot of them. The /40 was 16 bits, /50 32 bits, and /65 64 bits. The later /85 was roughly a /65 reimplemented in faster logic with a cache and 128 bit memory, making it as fast as the more expensive /91 for programs that didn't use a lot of floating point. The /85 was microcoded and could emulate a 7094. All the S/360s from the 65 and down had microcoded emulators for > 2nd generation IBM architectures such as the 1400. The emulators usually > ran faster than the real hardware. They always ran faster, company policy. That's why you needed a 360/65 to emulate a 7094. > The emulators were there to accommodate data centers that had lost their > source code for mission critical applications. Partly that, more that the emulators allowed the customers to spread the conversion work out partly before they got the new machine, partly after. Remember that the new machine was faster and had better peripherals. Since it was built with more modern components it may well have been cheaper to rent. > Knuth was right about multiple levels of emulation/interpretaton. The 5100 was indeed a marvel, but it was a very slow one. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From paul.winalski at gmail.com Sat Jul 13 02:51:25 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 12 Jul 2024 12:51:25 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> Message-ID: On Fri, Jul 12, 2024 at 12:23 PM John R Levine wrote: > On Thu, 11 Jul 2024, Paul Winalski wrote: > > Yes, that was precisely my point, and thank you for stating it more > clearly > > and concisely than I did. The VAX MACRO compiler takes in VAX assembly > > source code, not binary VAX instructions. > > Does anyone know how extensively they used the macro facilities? You can > write much higher level stuff as macros than as single instructions, which > makes it a lot easier to do efficient translation. For example, on OS/360 > you'd write a GET macro to retrieve the next record (or a pointer to it) > from a file, which was a lot easier to figure out than the control blocks > and subroutine calls the macros expanded into. > > Macros were used very extensively in VAX MACRO, both for user programming and in the operating system. All of the low-level system calls for user programs were implemented and documented as macros. The OS assembly code made heavy use of macros as well. Outside the VAX/VMS development group, BLISS was DEC's standard implementation language. In the development organizations I worked in (software development tools and compilers), we did almost zero programming in assembly code. The only assembly-level programming I ever did was the innermost loop of my VAX/VMS Mandelbrot set program and a device driver to implement Unix-style pipes on VMS. I did the latter in assembly code only because there was no documented HLL interface for writing VAX/VMS device drivers. As Clem Cole observed, Dave Cutler hated BLISS with a passion. All of his work on the VAX/VMS operating system was in assembly code. Because of this there is still a large amount of OpenVMS still written in VAX MACRO. But the RMS (Record Management Services, the VMS file system user interface) group wrote all of their code in BLISS. After leaving the VMS group Dave went on to design and implement a common compiler back end for VAX, the VAX Code Generator (VCG), which was the optimizer and back end for VAX PL/I, VAX C, and VAX Ada. The earlier generations of VAX/VMS compilers (VAX Fortran, VAX Pascal, VAX COBOL) each had their own back ends. Cutler later did get HLL religion. His real-time operating system for the VAX, VAXeln, was written almost entirely in Pascal. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Sat Jul 13 02:54:11 2024 From: johnl at taugh.com (John R Levine) Date: 12 Jul 2024 12:54:11 -0400 Subject: [COFF] [TUHS] Re: history of machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> Message-ID: <19ba8ede-c869-6453-40ac-fe51dc9eb323@taugh.com> On Wed, 10 Jul 2024, Dan Cross wrote: >< [[ Knuth described instruction by instruction simulation ]] > 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. Simulators that interpreted a pseudo-machine code date from the early 1950s. They were popular before compilers existed. Fortran and Flow-matic arrived in 1954, translating languages that were somewhat familiar to people into machine code, mathematical formulas for Fortran, business English for Flow-matic. But it would be rather a stretch to assert that anyone was doing machine code translation in 1954. It was a while until enough machine code existed for it to be worth thinking about, and the jump from tranlating from human-ish languages to translating from machine languages was likely far less obvious at the time than it is in retrosoect. On the other hand, there was UNCOL. In the 1950s people quckly realized that building a compiler for every language for every machine would be a lot of work, particularly in an era when there was such extreme variation in machine architecture. So someone came up with UNCOL which was supposed to be a UNiversal Computer Oriented Language, or what we would call a universal intermediate language. All of the compilers would translate the original language to UNCOL, and there wold be an UNCOL to machine language translator for each machine. This reduced the NxM compiler problem to N+M if it worked, which of course it didn't because the languages and the machines were both too varied. But UNCOL to machine code is in the same ballpark as machine to machine. CACM articles on UNCOL here: https://dl.acm.org/doi/10.1145/368892.368915 https://dl.acm.org/doi/10.1145/368919.3165711 I would still love to hear if there are any actual reports or papers or anecdotes of people doing machine code translation before the 1967 one that started this discussion. R's, John From johnl at taugh.com Sat Jul 13 03:02:46 2024 From: johnl at taugh.com (John R Levine) Date: 12 Jul 2024 13:02:46 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> Message-ID: <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> On Fri, 12 Jul 2024, Paul Winalski wrote: >> Macros were used very extensively in VAX MACRO, both for user programming > and in the operating system. All of the low-level system calls for user > programs were implemented and documented as macros. The OS assembly code > made heavy use of macros as well. Oh, no wonder the translator worked so well. > Outside the VAX/VMS development group, BLISS was DEC's standard > implementation language. In the development organizations I worked in > (software development tools and compilers), we did almost zero programming > in assembly code. ... When I was at Yale we did a fair amount of programming in BLISS-36 which was a pretty nice language once you wrapped your brain around some of its quirks like needing a dot for every memory reference. Our Vaxes ran Unix so it was all C other than a few things like tracking down a bug in the 11/750's microcode that broke an instruction in the inner loop of printf(). I had managed to get a cross-compiling environment working an a PDP-11 but Bill Joy found the bug at the same time so we used his patched version. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From stuff at riddermarkfarm.ca Sat Jul 13 03:03:19 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Fri, 12 Jul 2024 13:03:19 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> Message-ID: <82adce49-326e-47ea-502e-21b6e5a8bb59@riddermarkfarm.ca> On 2024-07-12 12:51, Paul Winalski wrote (in part): > > Macros were used very extensively in VAX MACRO, both for user > programming and in the operating system.  All of the low-level system > calls for user programs were implemented and documented as macros.  The > OS assembly code made heavy use of macros as well. I recall one place that used macros that were hundreds of lines long. They were a nightmare to maintain as they were so rigid -- not the right way write macros. S. From aki at insinga.com Sat Jul 13 03:37:33 2024 From: aki at insinga.com (Aron Insinga) Date: Fri, 12 Jul 2024 13:37:33 -0400 Subject: [COFF] system implementation languages e.g. BLISS (was: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?) In-Reply-To: References: Message-ID: <744f454d-36a3-4a76-a7fe-9934a77bd2a0@insinga.com> (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 > [...] 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 REG REG (',...' 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Jul 13 04:01:14 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 12 Jul 2024 14:01:14 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <82adce49-326e-47ea-502e-21b6e5a8bb59@riddermarkfarm.ca> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <82adce49-326e-47ea-502e-21b6e5a8bb59@riddermarkfarm.ca> Message-ID: On Fri, Jul 12, 2024 at 1:03 PM Stuff Received wrote: > > I recall one place that used macros that were hundreds of lines long. > They were a nightmare to maintain as they were so rigid -- not the right > way write macros. > > DEC BLISS has the most powerful macro facility that I've ever seen in any programming language. Ward Clark of DEC's Development Methods and Software Tools Group wrote a set of macros called "Portable BLISS" that provided a uniform means to access basic operating system services such as sequential file I/O and heap memory management. There were Portable BLISS implementations for much of the vast zoo of DEC operating systems (RSX-11, RSTS, RT-11, TOPS-10, TOPS-20, VMS). Some of the Portable BLISS macros were over a thousand lines long. They were all obscure and hard to maintain. Unix users will be familiar with the Obfuscated C Contest. Within DEC Engineering there was an Obfuscated BLISS Contest one year. The winner was Stan Rabinowitz, who used macros to produce a text that looked nothing like BLISS syntax. Stan said it would compile cleanly except for one semantic error and challenged us to figure out what that was. It turned out to be an illegal uplevel reference. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Jul 13 04:20:27 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 12 Jul 2024 14:20:27 -0400 Subject: [COFF] system implementation languages e.g. BLISS (was: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?) In-Reply-To: <744f454d-36a3-4a76-a7fe-9934a77bd2a0@insinga.com> References: <744f454d-36a3-4a76-a7fe-9934a77bd2a0@insinga.com> Message-ID: On Fri, Jul 12, 2024 at 1:45 PM Aron Insinga wrote: > 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 :-) ). > > Yes, BLISS-16, BLISS-32, and BLISS-64 have BYTE (and WORD also for BLISS-32/64 IIRC) as a way to allocate data items smaller than a BLISS value. Such a declaration also attaches an implicit default field reference to the identifier. In the case of BYTE SIGNED it is <0, 8, 1> and for BYTE <0,8,0>. So the expression: Y = .X was, in its completely expanded form: Y<0,8,0> = .X<0,8,1> Tying the BYTE and SIGNED attributes to the identifier cleaned up the clutter of all those angle-bracket field references. Similarly BLISS has VECTOR (one-dimensional, 0-based array), BLOCK (equivalent of C's struct), and BLOCKVECTOR (array of structures) data declaration attributes that carry implicit field and addressing semantics. Again, a convenience for the programmer that alleviates clutter and makes the program more readable. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Sat Jul 13 04:54:13 2024 From: aki at insinga.com (Aron Insinga) Date: Fri, 12 Jul 2024 14:54:13 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> Message-ID: Outside of product development, the internal DECSIM multi-level logic simulator and its CLI and compilers were also written in BLISS.  Most of these started out in BLISS-36 but they were all brought together with a fault simulation kernel on the VAX to take advantage of the larger address space. Some other internal VLSI CAD tools were also written in BLISS, although a few were written in more common languages.  The first (AFAIK) retargetable microcode assembler at DEC, MICRO, was written in MACRO-10; sources are on the net.  The next generation MICRO2 was written in BLISS and AFAIK the binary is available but the sources have sadly been lost.  Re: Paul's comment about the portable I/O library in BLISS: When I first encountered C, I used the Unix system calls to do I/O.  The "standard I/O" library was a very important addition to C's usability.  Similarly, when I first encountered BLISS-10, I had to type in a package from the DECUS documentation to call TOPS-10 to do I/O.  Getting the "XPORT" I/O (etc.) library for Common BLISS was invaluable for the CAD tools. People have repeatedly omitted I/O from the initial design of a language and relegated it to a library, but even if the language is intended to be used for a kernel, people learning the language ("Hello, world!") or using the language above the kernel for utilities will need to do I/O, so this library should be included in the language design from the very beginning.  I think this lesson has been learned by now.  Its fallout is recognized in Stroustrup's quote of a Bell Labs axiom, "Library design is language design, and vice versa." - Aron On 7/12/24 12:51, Paul Winalski wrote: > Outside the VAX/VMS development group, BLISS was DEC's standard > implementation language.  In the development organizations I worked in > (software development tools and compilers), we did almost zero > programming in assembly code. From johnl at taugh.com Sat Jul 13 06:35:17 2024 From: johnl at taugh.com (John Levine) Date: 12 Jul 2024 16:35:17 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <82adce49-326e-47ea-502e-21b6e5a8bb59@riddermarkfarm.ca> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0 Message-ID: <20240712203517.368748F78A81@ary.qy> It appears that Paul Winalski said: >> DEC BLISS has the most powerful macro facility that I've ever seen in any >programming language. ... Take a look at PL/I. Its preprocessor lets you use a large subset of PL/I including if, goto, and do loops and most of the string and arithmetic operators to write functions that run at compile time and put their results into the source file. And don't forget the IBM macro assembler. In macros along with all of the usual loops and local and global variables and subscripted parameters and conditional expressions and string processing, it had the AREAD op which read the next line from the source file and put it in a macro-time variable, thereby letting the macro define its own syntax from scratch if you wanted. There was also PUNCH to write a line directly to the object file. From dave at horsfall.org Sat Jul 13 06:52:48 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 13 Jul 2024 06:52:48 +1000 (EST) Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> Message-ID: On Sat, 12 Jul 2024, John R Levine wrote: > Our Vaxes ran Unix so it was all C other than a few things like tracking > down a bug in the 11/750's microcode that broke an instruction in the > inner loop of printf(). [...] Do tell... -- Dave From dave at horsfall.org Sat Jul 13 07:49:34 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 13 Jul 2024 07:49:34 +1000 (EST) Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> Message-ID: On Fri, 12 Jul 2024, Aron Insinga wrote: > Re: Paul's comment about the portable I/O library in BLISS: When I first > encountered C, I used the Unix system calls to do I/O.  The "standard > I/O" library was a very important addition to C's usability.  [...] As was the "Portable I/O Library" preceding it. -- Dave From johnl at taugh.com Sat Jul 13 08:03:28 2024 From: johnl at taugh.com (John Levine) Date: 12 Jul 2024 18:03:28 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240710212641.E24548F5C32C@ary.qy> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <18977302-8934-ec96-9154-b3c53824e506@ta Message-ID: <20240712220328.C332A8F7A3EF@ary.qy> It appears that Dave Horsfall said: >On Sat, 12 Jul 2024, John R Levine wrote: > >> Our Vaxes ran Unix so it was all C other than a few things like tracking >> down a bug in the 11/750's microcode that broke an instruction in the >> inner loop of printf(). [...] > >Do tell... The details are a litle dim after 45 years, but there was a MOVTUC instruction in the inner loop of printf that scanned for the null at the end of the string. The /750 had a microcode bug that didn't matter for the way DEC's software used it but broke the libc and I think also the kernel version. MOVTUC sets six registers and we probably used one they didn't. Bill replaced it with a few simpler instructions and the comment ; Comet sucks R's, John PS: For you young folks, Comet was DEC's internal project name for the /750. From aki at insinga.com Sat Jul 13 10:25:56 2024 From: aki at insinga.com (Aron Insinga) Date: Fri, 12 Jul 2024 20:25:56 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <20240712220328.C332A8F7A3EF@ary.qy> References: <20240710212641.E24548F5C32C@ary.qy> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <18977302-8934-ec96-9154-b3c53824e506@ta <20240712220328.C332A8F7A3EF@ary.qy> Message-ID: I think my work was in the summer of 1979 or possibly 1980, before the FRS in Oct. 1980.  People were happy because mass production of the ucode ROMs hadn't started yet.  I was using one of the 2~4 11/750 prototypes which were on concrete blocks in a lab, and the 11/730 breadboard was standing up on a table (no box) with its boards fanned out.  And it was during the gasoline shortage.  Maybe I'll find something about it later. - Aron On 7/12/24 18:03, John Levine wrote: > It appears that Dave Horsfall said: >> On Sat, 12 Jul 2024, John R Levine wrote: >> >>> Our Vaxes ran Unix so it was all C other than a few things like tracking >>> down a bug in the 11/750's microcode that broke an instruction in the >>> inner loop of printf(). [...] >> Do tell... > The details are a litle dim after 45 years, but there was a MOVTUC > instruction in the inner loop of printf that scanned for the null at > the end of the string. The /750 had a microcode bug that didn't > matter for the way DEC's software used it but broke the libc and > I think also the kernel version. MOVTUC sets six registers and > we probably used one they didn't. > > Bill replaced it with a few simpler instructions and the comment > > ; Comet sucks > > R's, > John > > PS: For you young folks, Comet was DEC's internal project name for the /750. From dave at horsfall.org Sat Jul 13 10:27:36 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 13 Jul 2024 10:27:36 +1000 (EST) Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <20240712220328.C332A8F7A3EF@ary.qy> References: <20240710212641.E24548F5C32C@ary.qy> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <18977302-8934-ec96-9154-b3c53824e506@ta <20240712220328.C332A8F7A3EF@ary.qy> Message-ID: On Sat, 12 Jul 2024, John Levine wrote: > The details are a litle dim after 45 years, but there was a MOVTUC > instruction in the inner loop of printf that scanned for the null at the > end of the string. The /750 had a microcode bug that didn't matter for > the way DEC's software used it but broke the libc and I think also the > kernel version. MOVTUC sets six registers and we probably used one they > didn't. I am reminded of the time when overlapped seeks on the RK-11 were implemented in Unix, per the Peripherals Handbook. They didn't work. DEC responded with "Well, you were running Unix!"... We then ran "DECEX" (their own diagnostic tool), which indeed failed on overlapped seekson the RK-11. It turned out that DEC never used overlapped seeks in their own stuff... -- Dave From paul.winalski at gmail.com Sat Jul 13 11:19:13 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 12 Jul 2024 21:19:13 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <20240712220328.C332A8F7A3EF@ary.qy> References: <20240710212641.E24548F5C32C@ary.qy> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240712220328.C332A8F7A3EF@ary.qy> Message-ID: On Fri, Jul 12, 2024 at 6:10 PM John Levine wrote: > > PS: For you young folks, Comet was DEC's internal project name for the > /750. > The first generation of VAXen were the 11-780 (codenamed Star), the 11/750 (Comet) and the 11/730 (Nebula). The 11/780's successor was to be implemented in ECL and was codenamed Venus. Along with Venus were a two-board VAX implementation (Gemini) and a one-board VAX (Scorpio). Gemini was cancelled. Venus had lots of schedule slippage but was eventually released, but under the new 4-digit VAX branding system (it was originally slated to be called the 11-790). Scorpio became the VAX 8000. -Paul W -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Sat Jul 13 12:25:14 2024 From: johnl at taugh.com (John Levine) Date: 13 Jul 2024 02:25:14 -0000 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> References: <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> Message-ID: According to Dave Horsfall : >I am reminded of the time when overlapped seeks on the RK-11 were >implemented in Unix, per the Peripherals Handbook. > >They didn't work. Yup, I recall looking at the disk drivers which had a comment saying that overlapped seeks on RK disks didn't work. At Yale our PDP-11 had a pair of 2314-style RP drives. Its controller did work and I stayed up all night one weekend debugging a driver that queued and sorted requests for the two drives separately and did separate seeks. It made a lot of difference, something like 30% more transfers/minute. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From ralph at inputplus.co.uk Sat Jul 13 19:26:47 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 13 Jul 2024 10:26:47 +0100 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: <20240712203517.368748F78A81@ary.qy> References: <82adce49-326e-47ea-502e-21b6e5a8bb59@riddermarkfarm.ca> <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0 <20240712203517.368748F78A81@ary.qy> Message-ID: <20240713092647.2DCD722067@orac.inputplus.co.uk> Hi, John Levine wrote: > Take a look at PL/I. Its preprocessor lets you use a large subset of > PL/I including if, goto, and do loops and most of the string and > arithmetic operators to write functions that run at compile time and > put their results into the source file. Another approach is for the language to offer evaluation at compile time. - FORTH had COMPILE and IMMEDIATE to switch modes; there's POSTPONE as well now. - Zig has comptime. https://ziglang.org/documentation/master/#comptime https://ziglang.org/documentation/master/#Case-Study-print-in-Zig -- Cheers, Ralph. From ralph at inputplus.co.uk Sat Jul 13 19:57:08 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 13 Jul 2024 10:57:08 +0100 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> Message-ID: <20240713095708.203D5220C9@orac.inputplus.co.uk> Hi, John and Paul wrote: > > > > The VAX MACRO compiler takes in VAX assembly source code, not > > > > binary VAX instructions. > > > > > > Does anyone know how extensively they used the macro facilities? > > > You can write much higher level stuff as macros than as single > > > instructions, which makes it a lot easier to do efficient > > > translation. > > > > Macros were used very extensively in VAX MACRO, both for user > > programming and in the operating system. All of the low-level > > system calls for user programs were implemented and documented as > > macros. The OS assembly code made heavy use of macros as well. > > Oh, no wonder the translator worked so well. Well, doesn't it depend on whether VAX MACRO kept the macros as high-level entities when translating them, or if it processed macros in the familiar way into instructions that sat at the same level as hand-written ‘assembler’. I don't think this thread has made that clear so far. -- Cheers, Ralph. From douglas.mcilroy at dartmouth.edu Sat Jul 13 21:09:47 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 13 Jul 2024 07:09:47 -0400 Subject: [COFF] machine code translation,as mental architecture models Message-ID: > Well, doesn't it depend on whether VAX MACRO kept the macros as > high-level entities when translating them, or if it processed macros in > the familiar way into instructions that sat at the same level as > hand-written ‘assembler’. I don't think this thread has made that clear > so far. The Multics case that I cited was definitely in the latter category. There was no "translator". Effectively there were just two different macro packages applied to the same source file. In more detail, there were very similar assemblers for the original IBM machines and the new GE machines. Since they didn't have "include" facilities, there were actually two source files that differed only in their macro definitions. The act of translation was to supply the latter set of definitions--a notably larger set than the former (which may well have been empty). Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Jul 13 23:17:16 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 13 Jul 2024 09:17:16 -0400 (EDT) Subject: [COFF] More LCM fallout Message-ID: <20240713131716.A741818C075@mercury.lcs.mit.edu> I just noticed this: Sep 2018: The Multics History Project Archives were donated to the Living Computer Museum in Seattle. This included 11 boxes of tapes, and 58 boxes of Multics and CTSS documentation and listings. What will happen to these items is unknown. https://multicians.org/multics-news.html#events That last sentence is ironic; I _assume_ it was written before the recent news. I wonder what will happen to all such material at the LCM. Anyone know? Noel From crossd at gmail.com Sun Jul 14 00:25:39 2024 From: crossd at gmail.com (Dan Cross) Date: Sat, 13 Jul 2024 10:25:39 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: <20240713095708.203D5220C9@orac.inputplus.co.uk> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: On Sat, Jul 13, 2024 at 5:57 AM Ralph Corderoy wrote: > John and Paul wrote: > > > > > The VAX MACRO compiler takes in VAX assembly source code, not > > > > > binary VAX instructions. > > > > > > > > Does anyone know how extensively they used the macro facilities? > > > > You can write much higher level stuff as macros than as single > > > > instructions, which makes it a lot easier to do efficient > > > > translation. > > > > > > Macros were used very extensively in VAX MACRO, both for user > > > programming and in the operating system. All of the low-level > > > system calls for user programs were implemented and documented as > > > macros. The OS assembly code made heavy use of macros as well. > > > > Oh, no wonder the translator worked so well. > > Well, doesn't it depend on whether VAX MACRO kept the macros as > high-level entities when translating them, or if it processed macros in > the familiar way into instructions that sat at the same level as > hand-written ‘assembler’. I don't think this thread has made that clear > so far. The non-VAX compilers for Macro-32 do expansion. That is, they don't just recognize macros and treat them as intrinsics or primitives that are specially optimized. Macro is not C, where you can treat "library" functions defined in the standard specially. John Reagan, of VSI, has posted about XMACRO (the Macro compiler for x86) in various places. For instance, here: https://comp.os.vms.narkive.com/F05qmMaD/x86-cross-tools-kit#post4 This post, and others, suggests to me that XMACRO is definitely doing macro expansion before compilation proper. - Dan C. From aki at insinga.com Sun Jul 14 03:27:56 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 13:27:56 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <0ef7503a-6ac3-711e-413d-52ea8e9c1fff@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: <6f1a9777-87c2-480a-83e3-926972b00e5f@insinga.com> On 7/13/24 10:25, Dan Cross wrote: > On Sat, Jul 13, 2024 at 5:57 AM Ralph Corderoy wrote: >> John and Paul wrote: >> Well, doesn't it depend on whether VAX MACRO kept the macros as >> high-level entities when translating them, or if it processed macros in >> the familiar way into instructions that sat at the same level as >> hand-written ‘assembler’. I don't think this thread has made that clear >> so far. The DEC assemblers [sic] for the PDP-11 and VAX-11 did macro expansion as text substitution. AA-V027A-TC PDP-11 MACRO-11 Language Reference Manual Section 7.1 (PDF file p 115, original document p 7-1) says "Macro expansion is the insertion of the macro source lines into the main program." Note: This manual also discusses concatenation with macro arguments and (on p 120 or p 7-6) macros that define other macros. AA-D032B-TE VAX-11 MACRO Language Reference Manual The beginning of chapter 6 (p 119 or p 6-1) says the same thing. At least in those assemblers, macros were not inline procedures. Google can find manuals for other assemblers.  For even earlier history, see https://github.com/PDP-10/its/issues/2032 http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sun Jul 14 03:36:20 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 13 Jul 2024 13:36:20 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: Message-ID: On Sat, Jul 13, 2024 at 9:35 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Well, doesn't it depend on whether VAX MACRO kept the macros as > > high-level entities when translating them, or if it processed macros in > > the familiar way into instructions that sat at the same level as > > hand-written ‘assembler’. I don't think this thread has made that clear > > so far. > > The VAX MACRO compiler treats macros the same way that the assembler treats them. It expands them into individual assembler statements (i.e., instructions, labels, data definitions, etc.). VAX MACRO then translates those into compiler intermediate language (originally GEM EIL [expanded intermediate language], nowadays probably LLVM IL). Neither the VAX assembler nor the VAX MACRO compiler treats macros as high-level entities. I know of no assembler that would do such a thing. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Sun Jul 14 04:50:14 2024 From: johnl at taugh.com (John Levine) Date: 13 Jul 2024 18:50:14 -0000 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240710203422.284BA18C077@mercury.lcs. <20240713095708.203D5220C9@orac.inputplus.co.uk> References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240710203422.284BA18C077@mercury.lcs. <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: According to Ralph Corderoy : >> Oh, no wonder the translator worked so well. > >Well, doesn't it depend on whether VAX MACRO kept the macros as >high-level entities when translating them, or if it processed macros in >the familiar way into instructions that sat at the same level as >hand-written ‘assembler’. I don't think this thread has made that clear >so far. It was a macro assembler. The macros generated assembler statements that got assembled the normal way. I agree with the person that every macro assembler I've ever seen did that. A semi-exception is the IBM assembler that also had a PUNCH statement that put records into the object file but I think that was only used to pass commands to the linker. The more relevant question is how they used the macros. If the macros were used consistently for semantically higher level things, the translator can use the semantics of the macros when translating. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From paul.winalski at gmail.com Sun Jul 14 05:27:12 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 13 Jul 2024 15:27:12 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: On Sat, Jul 13, 2024 at 2:50 PM John Levine wrote: > The more relevant question is how they used the macros. If the macros > were used consistently for semantically higher level things, the > translator can use the semantics of the macros when translating. > > There is an assembly macro for each of the user-mode VMS system services These are wrappers around the RTL subroutines. So, for example, the $QIO (queue I/O) macro is a wrapper around a call to the SYS$QIO runtime library routine. There is a similar set of macros for the RMS (record management services--the VMS file I/O system) data structures and routines. The VAX MACRO compiler could perhaps use the semantics of the macros when translating, but it doesn't. It has to support semantics-free macro expansion since users can write their own macros, so there is little point in building semantic knowledge into the translator. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Jul 14 05:42:24 2024 From: crossd at gmail.com (Dan Cross) Date: Sat, 13 Jul 2024 15:42:24 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: On Sat, Jul 13, 2024 at 2:50 PM John Levine wrote: > According to Ralph Corderoy : > >> Oh, no wonder the translator worked so well. > > > >Well, doesn't it depend on whether VAX MACRO kept the macros as > >high-level entities when translating them, or if it processed macros in > >the familiar way into instructions that sat at the same level as > >hand-written ‘assembler’. I don't think this thread has made that clear > >so far. > > It was a macro assembler. The macros generated assembler statements > that got assembled the normal way. I agree with the person that every > macro assembler I've ever seen did that. A semi-exception is the IBM > assembler that also had a PUNCH statement that put records into the > object file but I think that was only used to pass commands to the > linker. This is conflating two different things over the life of the MACRO-32 language. It certainly started out as a macro assembler, but with the introduction of the Alpha, DEC turned it into a true compiler (where the source language happens to be VAX assembly language) that generated native code for whatever machine it was compiled for: VAX or Alpha; using the GEM backends. When Compaq started the port to Itanium, they employed the same technique; this was maintained by HP. VSI has shifted to using LLVM as their compiler backend for the x86_64 port, with ELF as the executable file format (and presumably for object files as well). As I understand the current state of affairs, there is a GEM to LLVM layer that interfaces between the still-GEM output of compiler frontends and the LLVM backend, that performs native code generation. Macro, in particular, bypasses most of the LLVM optimization layer. > The more relevant question is how they used the macros. If the macros > were used consistently for semantically higher level things, the > translator can use the semantics of the macros when translating. As has been mentioned, they don't do this. The output of fully expanded MACRO-32 is basically VAX assembly language, which is then compiled in a manner similar to how one would compile preprocessed C. - Dan C. From crossd at gmail.com Sun Jul 14 05:51:34 2024 From: crossd at gmail.com (Dan Cross) Date: Sat, 13 Jul 2024 15:51:34 -0400 Subject: [COFF] [TUHS] Re: history of machine code translation, as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> <18977302-8934-ec96-9154-b3c53824e506@taugh.com> <19ba8ede-c869-6453-40ac-fe51dc9eb323@taugh.com> Message-ID: On Sat, Jul 13, 2024 at 1:35 PM John R Levine 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_Summary_Description.pdf > > (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_Summary_Description.pdf (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. From aki at insinga.com Sun Jul 14 07:05:01 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 17:05:01 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: Message-ID: <3e5e6a68-e557-4b03-96ea-949f4404c517@insinga.com> On 7/13/24 13:36, Paul Winalski wrote: > Neither the VAX assembler nor the VAX MACRO compiler treats macros as > high-level entities.  I know of no assembler that would do such a thing. > > -Paul W. This morning I would have agreed with you but I think I found a counter-example.  At MIT, there were 2 assemblers written for the TX-0 and later ported and retargeted to the PDP-1: MACRO (which DEC adopted) and then Midas (which MIT stayed with for the PDP-6 and PDP-10). The MIDAS assembler manual says that it copies characters from the macro body into the source program (as we would expect to happen today for a macro, as opposed to an inline procedure): http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf p 10 in the document says: When a macro instruction is called, MIDAS reads out the characters which form the macro-instruction definition, substitutes the characters of the arguments for the dummy arguments, and inserts the resulting characters into the source program as if typed there originally. However, the DEC PDP-1 MACRO assembler manual says that a macro call is expanded by copying the *sequence of 'storage words' and advancing the current location (.) for each word copied* (although it does replace labels with memory addresses): https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf p 19 in the document says: I am quite surprised. [For those who may not know, the TX-0 was built at MIT Lincoln Lab in 1956 and, when it was no longer useful for their research, it was moved onto the campus where the model railroad club found it and started hacking.  DEC was spun off from Lincoln Lab, with the result that the PDP-1 was very similar to the TX-0, and an early PDP-1 was installed in the room on campus next to the TX-0.  But that was all before my time.] - Aron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kLOsHOzErbke14PV.png Type: image/png Size: 29927 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Sun Jul 14 08:00:19 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 13 Jul 2024 18:00:19 -0400 Subject: [COFF] machine code translation,as mental architecture models Message-ID: > the DEC PDP-1 MACRO assembler manual says that a macro call > is expanded by copying the *sequence of 'storage words' and > advancing the current location (.) for each word copied* > I am quite surprised. I am, too. It seems that expansion is not recursive. And that it can only allocate storage word by word, not in larger blocks. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Sun Jul 14 09:46:44 2024 From: johnl at taugh.com (John Levine) Date: 13 Jul 2024 19:46:44 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: Message-ID: <20240713234644.AAD0B8F88DE4@ary.qy> It appears that Douglas McIlroy said: >-=-=-=-=-=- > >> the DEC PDP-1 MACRO assembler manual says that a macro call >> is expanded by copying the *sequence of 'storage words' and >> advancing the current location (.) for each word copied* > >> I am quite surprised. I looked at the manual and I think he's misreading it. The "words" in question are the tokens in the macro definition. The example macros look pretty straightforward, instructions and pseudo-ops that are expanded replacing dummy arguments by actual ones. There's no conditional assembly so each macro is just a parameterized chunk of code. https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf R's, John From crossd at gmail.com Sun Jul 14 10:54:33 2024 From: crossd at gmail.com (Dan Cross) Date: Sat, 13 Jul 2024 20:54:33 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <20240713234644.AAD0B8F88DE4@ary.qy> References: <20240713234644.AAD0B8F88DE4@ary.qy> Message-ID: A general housekeeping plea. When quoting someone's text, could we please use correct attributions? On Sat, Jul 13, 2024 at 7:46 PM John Levine wrote: > It appears that Douglas McIlroy said: It may appear so based on the quoted text, but in fact Doug did _not_ write the words reproduced here, but rather, was quoting someone else who did. In this case, Aron Insinga wrote the text below. Unfortunately, that this is Aron's contribution to the discussion is not mentioned anywhere in the quoted portion. Of course mistakes happen, but it's been happening with increasing frequency lately, and it's not particularly fair to either the person who made the original contribution or the person to whom the quotes are misattributed. Thanks! - Dan C. > >-=-=-=-=-=- > > > >> the DEC PDP-1 MACRO assembler manual says that a macro call > >> is expanded by copying the *sequence of 'storage words' and > >> advancing the current location (.) for each word copied* > > > >> I am quite surprised. > > I looked at the manual and I think he's misreading it. The "words" in > question are the tokens in the macro definition. > > The example macros look pretty straightforward, instructions and > pseudo-ops that are expanded replacing dummy arguments by actual ones. > There's no conditional assembly so each macro is just a parameterized > chunk of code. > > https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf > > R's, > John From aki at insinga.com Sun Jul 14 10:56:41 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 20:56:41 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <20240713234644.AAD0B8F88DE4@ary.qy> References: <20240713234644.AAD0B8F88DE4@ary.qy> Message-ID: <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> On 7/13/24 19:46, John Levine wrote: > It appears that Douglas McIlroy said: >> -=-=-=-=-=- >> >>> the DEC PDP-1 MACRO assembler manual says that a macro call >>> is expanded by copying the *sequence of 'storage words' and >>> advancing the current location (.) for each word copied* >>> I am quite surprised. > I looked at the manual and I think he's misreading it. The "words" in > question are the tokens in the macro definition. > > The example macros look pretty straightforward, instructions and > pseudo-ops that are expanded replacing dummy arguments by actual ones. > There's no conditional assembly so each macro is just a parameterized > chunk of code. > > https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf > > R's, > John Possibly, but they use 'syllables' for tokens (symbols or integers), and they say here that they advance the location counter after each word copied.  If they were copying characters into the input stream, they would not be incrementing the location counter ('.') after each word transferred. And as you say, it is simple parameter substitution, so tracking which macro argument goes into which instruction's address field is easy.  The instruction format is simple.  So for each line in the macro definition body, if the opcode is a memory reference instruction, put the argument number in the binary instruction address field before storing the instruction word in a list/block. When expanding the macro, if the opcode is a memory reference instruction, get the argument number from the address field and replace it with the symbol table value of the symbol passed in as the actual argument, and store the word in the output stream (and incrememnt '.'). I haven't yet gotten the 18-bit-but-incompatible PDP-4 documentation for comparison.  [IIRC the PDP-4 assembler was the one with a single pass assembler that punched the symbol table at the end of the tape, and the clever loader that read the tape upside down and backwards to first rebuild the symbol table and then fix up the instructions and load them into memory.] - Aron From aki at insinga.com Sun Jul 14 11:04:47 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 21:04:47 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <20240713234644.AAD0B8F88DE4@ary.qy> Message-ID: I think this is correctly patched: On 7/13/24 19:46, John Levine wrote: >> Aron Insinga said: >> >> the DEC PDP-1 MACRO assembler manual says that a macro call >> is expanded by copying the *sequence of 'storage words' and >> advancing the current location (.) for each word copied* >> I am quite surprised. I looked at the manual and I think he's misreading it. The "words" in question are the tokens in the macro definition. The example macros look pretty straightforward, instructions and pseudo-ops that are expanded replacing dummy arguments by actual ones. There's no conditional assembly so each macro is just a parameterized chunk of code. https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf R's, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Sun Jul 14 11:09:07 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 21:09:07 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: <79b48bb7-1ced-43f9-a8ca-afcfc3dc24c2@insinga.com> Back to topic of machine code translation, I stumbled over this paper describing DEC's migration from VAX (VMS) or MIPS (Ultrix) to Alpha (VMS or OSF/1, respectively) for user-mode applications.  The paper states that this included hand-coded assembly language applications. https://web.stanford.edu/class/cs343/resources/binary-translation.pdf From aki at insinga.com Sun Jul 14 11:46:06 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 13 Jul 2024 21:46:06 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: On 7/13/24 15:42, Dan Cross wrote: > The output of fully expanded MACRO-32 is basically VAX assembly language, which is then > compiled in a manner similar to how one would compile preprocessed C. > > - Dan C. Although, a minor point, the macro definition & expansion, conditional assembly, etc. are all done on the fly as the assembly language source file is read.  There's no separate macro processing pass like on Unix when, if the first character of the .c file was '#', cpp read the .c file and generated a .i file to pass to the compiler proper (which let cpp be used on Pascal, assembler, and who knows what else). - Aron -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Mon Jul 15 01:55:19 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 14 Jul 2024 11:55:19 -0400 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: <3e5e6a68-e557-4b03-96ea-949f4404c517@insinga.com> References: <3e5e6a68-e557-4b03-96ea-949f4404c517@insinga.com> Message-ID: On Sat, Jul 13, 2024 at 5:20 PM Aron Insinga wrote: > On 7/13/24 13:36, Paul Winalski wrote: > > Neither the VAX assembler nor the VAX MACRO compiler treats macros as > high-level entities. I know of no assembler that would do such a thing. > > -Paul W. > > > > This morning I would have agreed with you but I think I found a > counter-example. At MIT, there were 2 assemblers written for the TX-0 and > later ported and retargeted to the PDP-1: MACRO (which DEC adopted) and > then Midas (which MIT stayed with for the PDP-6 and PDP-10). > > The MIDAS assembler manual says that it copies characters from the macro > body into the source program (as we would expect to happen today for a > macro, as opposed to an inline procedure): > http://www.bitsavers.org/pdf/mit/rle_pdp1/memos/PDP-1_MIDAS.pdf > p 10 in the document says: > > When a macro instruction is called, MIDAS reads out the characters which > form the macro-instruction definition, substitutes the characters of the > arguments for the dummy arguments, and inserts the resulting characters > into the source program as if typed there originally. > > However, the DEC PDP-1 MACRO assembler manual says that a macro call is > expanded by copying the *sequence of 'storage words' and advancing the > current location (.) for each word copied* (although it does replace labels > with memory addresses): > https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf > p 19 in the document says: > > > Those two quotes from the documentation are saying the same thing. The MACRO quote says the process is this: 1. Evaluate the expressions in the argument list of the macro. 2. Substitute these values for the dummy symbols in the macro. 3. Process the resulting text exactly the same way as non-macro input to the assembler. 4. Place the resulting binary machine words into the object file. Steps (1) and (2) match what the Midas text says. Steps (3) and (4) are conventional processing of assembler input. There is nothing unusual here. MACRO is decidedly NOT treating the macro calls as higher-level entities. It is doing simple text substitution and then treating it as it would any other input. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kLOsHOzErbke14PV.png Type: image/png Size: 29927 bytes Desc: not available URL: From paul.winalski at gmail.com Mon Jul 15 02:16:21 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 14 Jul 2024 12:16:21 -0400 Subject: [COFF] machine code translation, as mental architecture models In-Reply-To: References: <2f46e2da-8250-0fd3-43f9-e33aae0739c5@taugh.com> <20240713095708.203D5220C9@orac.inputplus.co.uk> Message-ID: On Sat, Jul 13, 2024 at 4:00 PM Dan Cross wrote: > > This is conflating two different things over the life of the MACRO-32 > language. It certainly started out as a macro assembler, but with the > introduction of the Alpha, DEC turned it into a true compiler (where > the source language happens to be VAX assembly language) that > generated native code for whatever machine it was compiled for: VAX or > Alpha; using the GEM backends. > > The confusion arises because the name VAX MACRO was used for two completely independent and very different software tools. The first VAX MACRO was the conventional assembler for VAX/VMS, developed in the mid-1970s. It had conventional macroinstruction capabilities, hence the name. An inconveniently large amount of the VAX/VMS operating system code was written in VAX assembly language. Dave Cutler didn't believe in using higher level languages for system code, and he despised BLISS (DEC's standard HLL language for software product development) in particular. To migrate VMS to Alpha it was decided that the quickest and least error-prone path was to write a compiler front end that takes VAX MACRO syntax and generates expanded intermediate language (EIL) for the GEM compiler back end. GEM then generates the Alpha code and writes it into an object file. This work was done circa 1990. The name "VAX MACRO" was used for this compiler as well as for the previous assembler. > When Compaq started the port to Itanium, they employed the same > technique; this was maintained by HP. > > No further work needed to be done in the VAX MACRO compiler front end to support Itanium. All that needed to be done was to add Itanium code generation capability to the GEM back end. After that all GEM-based compilers acquired Itanium code generation capability. That is the big advantage of having a common back end for all compilers. Over its lifetime GEM could generate object files for the MIPS, Alpha, and IA-32 machine architectures and for the VMS, Ultrix, OSF-1, and Windows operating systems. VSI has shifted to using LLVM as their compiler backend for the x86_64 > port, with ELF as the executable file format (and presumably for > object files as well). As I understand the current state of affairs, > there is a GEM to LLVM layer that interfaces between the still-GEM > output of compiler frontends and the LLVM backend, that performs > native code generation. Macro, in particular, bypasses most of the > LLVM optimization layer. > > VAX MACRO also bypassed most of GEM's optimization layer as well. And yes, most (if not all) of the legacy OpenVMS compilers use a GEM-to-LLVM IL translator. VSI has more than enough on their plate without taking on a wholesale rewrite of the IL generators in the compiler front ends. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Jul 15 03:29:07 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 14 Jul 2024 12:29:07 -0500 Subject: [COFF] machine code translation,as mental architecture models In-Reply-To: References: <3e5e6a68-e557-4b03-96ea-949f4404c517@insinga.com> Message-ID: <20240714172907.yrliprtbp23rk764@illithid> At 2024-07-14T11:55:19-0400, Paul Winalski wrote: > > However, the DEC PDP-1 MACRO assembler manual says that a macro call > > is expanded by copying the *sequence of 'storage words' and > > advancing the current location (.) for each word copied* (although > > it does replace labels with memory addresses): > > https://bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf > > p 19 in the document says: [snip] Nothing destines a typeface for quaintness like naming it "Futura". Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From johnl at taugh.com Mon Jul 15 04:02:35 2024 From: johnl at taugh.com (John Levine) Date: 14 Jul 2024 18:02:35 -0000 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: <20240713234644.AAD0B8F88DE4@ary.qy> <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> References: <20240713234644.AAD0B8F88DE4@ary.qy> <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> Message-ID: According to Aron Insinga : >On 7/13/24 19:46, John Levine wrote: >> I looked at the manual and I think he's misreading it. The "words" in >> question are the tokens in the macro definition. ... >Possibly, but they use 'syllables' for tokens (symbols or integers), and >they say here that they advance the location counter after each word >copied.  If they were copying characters into the input stream, they >would not be incrementing the location counter ('.') after each word >transferred. If you really want to know what it did, here's the internals manual. The description of the macro facility starts on page 19 and it is quite clear that they're storing a tokenized version of the macros, so they're not copying characters, but they're not just copying assembled instructions either. https://bitsavers.org/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf The macro instruction facility in MACRO is both the strongest and weakest part of the program. It is the strongest in the sense that it is thot part of the program which contributes most toward ease of programming, especially in setting up tables of specialized format. It is the weakest in that it is quite inflexible and does not incorporate any of the more significant improvements in assembler technology that have occurred since the logic was first written in 1957. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From aki at insinga.com Mon Jul 15 11:44:37 2024 From: aki at insinga.com (Aron Insinga) Date: Sun, 14 Jul 2024 21:44:37 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: References: <20240713234644.AAD0B8F88DE4@ary.qy> <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> Message-ID: <980ed84f-8d93-4940-bd01-51bea7b10d18@insinga.com> On 7/14/24 14:02, John Levine wrote: > According to Aron Insinga: >> On 7/13/24 19:46, John Levine wrote: >>> I looked at the manual and I think he's misreading it. The "words" in >>> question are the tokens in the macro definition. ... >> Possibly, but they use 'syllables' for tokens (symbols or integers), and >> they say here that they advance the location counter after each word >> copied.  If they were copying characters into the input stream, they >> would not be incrementing the location counter ('.') after each word >> transferred. > If you really want to know what it did, here's the internals manual. > The description of the macro facility starts on page 19 and it is > quite clear that they're storing a tokenized version of the macros, so > they're not copying characters, but they're not just copying assembled > instructions either. > > https://bitsavers.org/pdf/dec/pdp1/F36P_PDP1_Macro_Internals.pdf Thank you!!  I found the PDP-1 and TX-0 MACRO sources and was sadly unsurprised by the lack of comments, so they are difficult reading. http://www.bitsavers.org/bits/DEC/pdp1/papertapeImages/20040106/macro_6-63/_text/part2.txt They are not storing tokens.  In fact, the list of 'codes' for items stored as the macro body on p 20 is:     a storage word,     a dummy symbol specification.     a constant,     a dummy symbol parameter assignment, or     an end marker. So it is not storing tokens for instructions, just storage words (instructions or data) as mentioned in the user manual. In the discussion in the internals manual, after the paragraph mentioning the year this was designed (a nice touch), they say that they are storing the macro body as 'partially assembled' 'words' into which the dummy symbols are 'inserted'.  (And in a single-address architecture with a small memory address, addition is enough to do that insertion.)  They explain why they did this instead of storing characters: They do not look at the opcode as I suggested was possible, they have a more general solution that works for a word containing either code or data. I think that this may be (at least as far as any of us know) a unique case from the early days of computing where, on the TX-0 and a port to the PDP-1, a macro body *is* stored as a list of 'machine words' instead of source text.  The macro  body is not manipulated as a 'higher-level construct', it is just used for quite limited macro expansion. This has NO bearing on what DEC/HP/VSI did more than two decades later for the Alpha, Itanic, and x86_64 (where macros are expanded by the conventional insertion of characters from the macro body into the source text stream). - Aron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1RaBLgOaK9W7nogv.png Type: image/png Size: 101224 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Mon Jul 15 22:37:57 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 15 Jul 2024 08:37:57 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models Message-ID: In 1959, when Doug Eastwood and I, at the suggestion of George Mealy, set out to add macro capability to SAP (Share assembly program), the word "macro"--short for "macroinstruction"--was in the air, though none of us had ever seen a macroprocessor. We were particularly aware that GE had a macro-capable assembler. I still don't know where or when the term was coined. Does anybody know? We never considered anything but recursive expansion, where macro definitions can contain macro calls; thus the TX-0 model comes as quite a surprise. We kept a modest stack of the state of each active macro expansion. We certainly did not foresee that within a few years some applications would need a 70-level stack! General stack-based programming was not common practice (and the term "stack" did not yet exist). This caused disaster the first time we wrote a macro that generated a macro definition, because a data-packing subroutine with remembered state, which was used during both definition and expansion, was not reentrant. To overcome the bug we had in effect to introduce another small stack to keep the two uses out of each other's way. Luckily there were no more collisions between expansion and definition. Moreover, this stack needed to hold only one suspended state because expansion could trigger definition but not vice versa. Interestingly, the problem in the previous paragraph is still with us 65 years later in many programming languages. To handle it gracefully, one needs coroutines or higher-order functions. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jul 16 00:09:15 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 15 Jul 2024 10:09:15 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: <980ed84f-8d93-4940-bd01-51bea7b10d18@insinga.com> References: <20240713234644.AAD0B8F88DE4@ary.qy> <6a0f5b10-a2df-4117-b0ea-71802b6a7c26@insinga.com> <980ed84f-8d93-4940-bd01-51bea7b10d18@insinga.com> Message-ID: On Sun, Jul 14, 2024 at 9:44 PM Aron Insinga wrote: > I think that this may be (at least as far as any of us know) a unique case > from the early days of computing where, on the TX-0 and a port to the > PDP-1, a macro body *is* stored as a list of 'machine words' instead of > source text. The macro body is not manipulated as a 'higher-level > construct', it is just used for quite limited macro expansion. > Thanks for clearing this up. I think you're right that this is a unique case. All assemblers I've ever dealt with expanded macros into text that was then fed to the assember's parser just as if it were ordinary source program text. On a machine with limited memory it makes sense not to have to re-parse the expanded source after macro expansion, but instead to do the translation on the fly. It saves a second pass over the expanded macro call. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jul 16 00:26:18 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 15 Jul 2024 10:26:18 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: References: Message-ID: On Mon, Jul 15, 2024 at 8:46 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > We never considered anything but recursive expansion, where macro > definitions can contain macro calls; thus the TX-0 model comes as quite a > surprise. We kept a modest stack of the state of each active macro > expansion. We certainly did not foresee that within a few years some > applications would need a 70-level stack! > > As I mentioned in a previous reply, BLISS has a very powerful and extensive macro facility. This led to an obscure and difficult to fix parser bug. The outermost organizational unit of a BLISS program is the module. All declarations, routines, identifiers, etc. have a syntactic scope limited to the module in which they occur. Modules are delimited by the keywords MODULE and ELUOM (module spelt backwards). The bug was triggered by a call to a macro that included an ELUDOM followed by a new MODULE declaration. When the parser saw the ELUDOM it threw away all of the context for the current module, including the parser context for the macro that was being processed. The parser blew its brains out and the compilation terminated with an internal compiler error. -Paul W. P. S. - I once remarked that in BLISS we don't solve problems, we ELUDOM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jul 16 00:38:14 2024 From: coff at tuhs.org (Bakul Shah via COFF) Date: Mon, 15 Jul 2024 07:38:14 -0700 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: References: Message-ID: On Jul 15, 2024, at 7:26 AM, Paul Winalski wrote: > > Modules are delimited by the keywords MODULE and ELUOM (module spelt backwards) I wonder who was the person who came up with the idea of reversing the beginning keyword to end the corresponding block in Algol68. From athornton at gmail.com Tue Jul 16 01:29:49 2024 From: athornton at gmail.com (Adam Thornton) Date: Mon, 15 Jul 2024 08:29:49 -0700 Subject: [COFF] The inexorable passage of time Message-ID: I was idly leafing through Padlipsky's _Elements Of Network Style_ the other day, and on page 72, he was imagining a future in which a cigar-box sized PDP-10 would be exchanging data with a breadbox-sized S/370. And here we are, only 40 years later, and 3 of my PDP-10s and my S/370 are all running on the same cigarette-pack sized machine, which cost something like $75 ($25 in 1984 dollars). Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jul 16 02:05:40 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 15 Jul 2024 09:05:40 -0700 Subject: [COFF] The inexorable passage of time In-Reply-To: References: Message-ID: <20240715160540.GB5559@mcvoy.com> I _loved_ Mike's book but it was because I read it at the right time. I had ported Lachman's (really Coherent's but Lachman owned the code then) TCP/IP stack to System 5. I thought I knew what I was doing but I didn't, not by a long stretch. I read Mike's book and it was like TCP/IP came into focus for me. I think if you knew too little, or too much, you wouldn't appreciate that book. I read it at the perfect time and I have to say, I think I got more from that book than any other CS book. And his quotes are funny and awesome. On Mon, Jul 15, 2024 at 08:29:49AM -0700, Adam Thornton wrote: > I was idly leafing through Padlipsky's _Elements Of Network Style_ the > other day, and on page 72, he was imagining a future in which a cigar-box > sized PDP-10 would be exchanging data with a breadbox-sized S/370. > > And here we are, only 40 years later, and 3 of my PDP-10s and my S/370 are > all running on the same cigarette-pack sized machine, which cost something > like $75 ($25 in 1984 dollars). > > Adam -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From johnl at taugh.com Tue Jul 16 05:39:16 2024 From: johnl at taugh.com (John Levine) Date: 15 Jul 2024 15:39:16 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: References: Message-ID: <20240715193917.5828C8F9FBE0@ary.qy> It appears that Douglas McIlroy said: >In 1959, ... >We never considered anything but recursive expansion, where macro >definitions can contain macro calls; thus the TX-0 model comes as quite a >surprise. We kept a modest stack of the state of each active macro >expansion. We certainly did not foresee that within a few years some >applications would need a 70-level stack! As the PDP-1 Macro imeplementation manual said about the macro feature: It is the weakest in that it is quite inflexible and does not incorporate any of the more significant improvements in assembler technology that have occurred since the logic was first written in 1957. The PDP-1 was not a very big machine, only 4K words and the only standard I/O device was paper tape, so no overlays or multiple passes. I can imagine that while they knew how to write a better macro processor, they didn't want to use up the memory it would have needed. Bitsavers has a bunch of memos about the TX-0. Memo 39 describes TX-0 assembler as of 1962, which had real macros that could insert arbitrary strings, as they show in an example on pages 10-11. https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf There are earlier memos about MACRO in 1959 and 1961 which suggest a weaker macro facility but don't have details. R's, John From aki at insinga.com Wed Jul 17 05:55:52 2024 From: aki at insinga.com (Aron Insinga) Date: Tue, 16 Jul 2024 15:55:52 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: <20240715193917.5828C8F9FBE0@ary.qy> References: <20240715193917.5828C8F9FBE0@ary.qy> Message-ID: <142b1dea-aacd-45fb-b094-0e44acf43278@insinga.com> On 7/15/24 15:39, John Levine wrote: > It appears that Douglas McIlroy said: >> In 1959, ... >> We never considered anything but recursive expansion, where macro >> definitions can contain macro calls; thus the TX-0 model comes as quite a >> surprise. We kept a modest stack of the state of each active macro >> expansion. We certainly did not foresee that within a few years some >> applications would need a 70-level stack! > As the PDP-1 Macro imeplementation manual said about the macro feature: > > It is the weakest > in that it is quite inflexible and does not incorporate any of the more significant improvements > in assembler technology that have occurred since the logic was first written in 1957. > > The PDP-1 was not a very big machine, only 4K words and the only > standard I/O device was paper tape, so no overlays or multiple passes. > I can imagine that while they knew how to write a better macro > processor, they didn't want to use up the memory it would have needed. > > Bitsavers has a bunch of memos about the TX-0. > > Memo 39 describes TX-0 assembler as of 1962, which had real macros > that could insert arbitrary strings, as they show in an example on > pages 10-11. > > https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf > > There are earlier memos about MACRO in 1959 and 1961 which suggest a weaker > macro facility but don't have details. > > R's, > John At MIT they wrote two assemblers on the TX-0, and retargeted/ported both of them to the PDP-1.  (The machines were in adjacent rooms at the time.  Their architectures were very similar.) * MACRO (macro expansion by limited partly-assembed memory words). DEC adopted MACRO, but its later MACRO assemblers do not seem to be at all based on that one. * Midas (generalized macro expansion by inserting a character sequence).  MIT chose Midas for future work, and they rewrote it for the PDP-6, so that's what you find on ITS. One of these retargets/ports was a challenge by Jack Dennis to a group of 4 or 5 students (the original hackers from the Tech Model Railroad Club) to do it over a weekend. I agree, there is a lot of great stuff in these memos, from both MIT and from DEC, and in the oral histories done by the Computer History Museum and/or  the Smithsonian. Bitsavers also has the hardware details, although they are in a very old notation, more abbreviated circuit schematics than logic diagrams.. - Aron From aki at insinga.com Wed Jul 17 06:09:01 2024 From: aki at insinga.com (Aron Insinga) Date: Tue, 16 Jul 2024 16:09:01 -0400 Subject: [COFF] ancient macros, machine code translation, as mental architecture models In-Reply-To: <142b1dea-aacd-45fb-b094-0e44acf43278@insinga.com> References: <20240715193917.5828C8F9FBE0@ary.qy> <142b1dea-aacd-45fb-b094-0e44acf43278@insinga.com> Message-ID: <19a6ad7e-c5fd-4779-bcb2-b95c5654a3ee@insinga.com> On 7/16/24 15:55, Aron Insinga wrote: > On 7/15/24 15:39, John Levine wrote: >> It appears that Douglas McIlroy said: >>> In 1959, ... >>> We never considered anything but recursive expansion, where macro >>> definitions can contain macro calls; thus the TX-0 model comes as >>> quite a >>> surprise. We kept a modest stack of the state of each active macro >>> expansion. We certainly did not foresee that within a few years some >>> applications would need a 70-level stack! >> As the PDP-1 Macro imeplementation manual said about the macro feature: >> >>     It is the weakest >>    in that it is quite inflexible and does not incorporate any of the >> more significant improvements >>    in assembler technology that have occurred since the logic was >> first written in 1957. >> >> The PDP-1 was not a very big machine, only 4K words and the only >> standard I/O device was paper tape, so no overlays or multiple passes. >> I can imagine that while they knew how to write a better macro >> processor, they didn't want to use up the memory it would have needed. >> >> Bitsavers has a bunch of memos about the TX-0. >> >> Memo 39 describes TX-0 assembler as of 1962, which had real macros >> that could insert arbitrary strings, as they show in an example on >> pages 10-11. >> >> https://bitsavers.org/pdf/mit/tx-0/memos/M-5001-39_MIDAS_Nov62.pdf >> >> There are earlier memos about MACRO in 1959 and 1961 which suggest a >> weaker >> macro facility but don't have details. >> >> R's, >> John > > At MIT they wrote two assemblers on the TX-0, and retargeted/ported > both of them to the PDP-1.  (The machines were in adjacent rooms at > the time.  Their architectures were very similar.) > > * MACRO (macro expansion by limited partly-assembed memory words). DEC > adopted MACRO, but its later MACRO assemblers do not seem to be at all > based on that one. > > * Midas (generalized macro expansion by inserting a character > sequence).  MIT chose Midas for future work, and they rewrote it for > the PDP-6, so that's what you find on ITS. > > One of these retargets/ports was a challenge by Jack Dennis to a group > of 4 or 5 students (the original hackers from the Tech Model Railroad > Club) to do it over a weekend. > > I agree, there is a lot of great stuff in these memos, from both MIT > and from DEC, and in the oral histories done by the Computer History > Museum and/or  the Smithsonian. > > Bitsavers also has the hardware details, although they are in a very > old notation, more abbreviated circuit schematics than logic diagrams.. p.s. That was too sweeping of a statement.  For the machines built by MIT, I found block diagrams and some instruction flows and lots of memos, but not the clock distribution matrix details.  Since the WW clock distribution matrix (ROM) triggered Wilkes' invention of microprogramming, I'd love to compare WW's with their later machines'.  And I haven't found more than a little on Wes Clark's later machines, L-1 and ARC-1.  I know some info is in the U. Wash. archives.  So many curiosities, so little time. :-) Best, - Aron From aki at insinga.com Thu Jul 18 03:00:30 2024 From: aki at insinga.com (Aron Insinga) Date: Wed, 17 Jul 2024 13:00:30 -0400 Subject: [COFF] ancient macros In-Reply-To: <19a6ad7e-c5fd-4779-bcb2-b95c5654a3ee@insinga.com> References: <20240715193917.5828C8F9FBE0@ary.qy> <142b1dea-aacd-45fb-b094-0e44acf43278@insinga.com> <19a6ad7e-c5fd-4779-bcb2-b95c5654a3ee@insinga.com> Message-ID: <6d80b875-0d51-40e7-8848-233b58d82cbe@insinga.com> This has nothing to do with compiling to code for other architectures!  This is just for the record regarding the history of *assemblers*. Here is a 1984 version of the DEC VAX-11 MACRO-32 *assembler* source listings: http://www.bitsavers.org/pdf/dec/vax/microfiche/vms-source-listings/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/059__MACRO/ Unfortunately, they don't have the ASCII text attached, so you can't search.  Go up a level to find the linker, etc. - Aron From ik at sjmulder.nl Thu Jul 18 04:20:57 2024 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Wed, 17 Jul 2024 20:20:57 +0200 Subject: [COFF] Commodity hardware for paper terminal experience Message-ID: <20240717202057.f2a08545382ee5a9b64fe85d@sjmulder.nl> Hi all, Some time ago I dived into ed and tried programming with it a bit. It was an interesting experience but I feel like the scrolling visual terminal can't properly emulate the paper terminal. You can't do rip out a printout and put it next to you, scribble on it, etc. I'd like to try replicating the experience more closely but I'm not interested in acquiring collector's items or complex mechanical hardware. There don't seem to be contemporary equivalents of the TI Silent 700 so I've been looking at are standalone printing devices to combine with a keyboard. But the best I can find is line printing, which is unsuitable for input. Any suggestions? Sijmen From clemc at ccc.com Thu Jul 18 05:01:12 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 17 Jul 2024 15:01:12 -0400 Subject: [COFF] Commodity hardware for paper terminal experience In-Reply-To: <20240717202057.f2a08545382ee5a9b64fe85d@sjmulder.nl> References: <20240717202057.f2a08545382ee5a9b64fe85d@sjmulder.nl> Message-ID: Sure, cheap 9 or 24-pin dot matrix printers are still sold new, and you can find them at thrift stores pretty easily. I'd take something like an Arduino and add a PC keyboard and dot matrix printer. You can emulate something as the limited functionality as an ASR33, but since that is Upper Case only and technical 10CPS, I recommend either emulating the ASR37 or the DEC LA120. I've forgotten the specs on the former, but it had some interesting tricks that programs like nroff(1) know about. The latter could print as fast as 120 cps, although it could talk and buffer the input data to be printed at much faster speeds and actually did some smart tricks like printing backward if that was going to be faster ᐧ On Wed, Jul 17, 2024 at 2:21 PM Sijmen J. Mulder wrote: > Hi all, > > Some time ago I dived into ed and tried programming with it a bit. It > was an interesting experience but I feel like the scrolling > visual terminal can't properly emulate the paper terminal. You can't do > rip out a printout and put it next to you, scribble on it, etc. > > I'd like to try replicating the experience more closely but I'm not > interested in acquiring collector's items or complex mechanical > hardware. There don't seem to be contemporary equivalents of the TI > Silent 700 so I've been looking at are standalone printing devices to > combine with a keyboard. But the best I can find is line printing, > which is unsuitable for input. > > Any suggestions? > > Sijmen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Fri Jul 19 04:16:12 2024 From: johnl at taugh.com (John R Levine) Date: 18 Jul 2024 14:16:12 -0400 Subject: [COFF] [TUHS] Re: UNIX Roff Manual In-Reply-To: References: <20240718015854.80FF28FF980D@ary.qy> Message-ID: <5467e22e-0b56-ef23-e114-83865b914ddd@taugh.com> > Yeah, I wasn't specific enough. > The ownership of the model 67 changed to the State of NJ, but it was > operated and present at Princeton, until replaced by a 370/158, which in > turn changed owners back to Princeton in 75. > > What OS did you use on the 67? On the /67 I used TSS with a free account they gave me for being in a local computer club. On the /91 I mostly used the free stuff but one summer in the early 70s I had a job speeding up an Ecom professor's Fortran model. Compiling it with Fortran H rather than G, and adjusting an assembler routine that managed an external file not to open and close the file on every call helped a lot. Paul Hilfinger had a long career at UC Berkeley and is easy to find if you want to ask him if he has any of his old papers. R's, John > > On Wed, Jul 17, 2024 at 6:58 PM John Levine wrote: > >> It appears that Tom Lyon said: >>> -=-=-=-=-=- >>> >>> Jonathan - awesome! >>> Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the >>> summer of 1969 by the 360/91. >> >> No, the /67 and /91 were there at the same time. I used them both in high >> school. >> I graduated in 1971 so that must have been 1969 to 71, and when I left I'm >> pretty >> sure both were still there. >> >> R's, >> John >> >> >>> BWK must've got started on the 7094 that preceded the 67, but since it was >>> FORTRAN the port wasn't hard. >>> Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. >>> >>> I graduated in 1978, ROFF usage was still going strong! >>> >>> On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray wrote: >>> >>>> On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: >>>>> On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < >>>> segaloco at protonmail.com> wrote: >>>>> >>>>>> Just sharing a copy of the Roff Manual that I had forgotten I >> scanned a little while back: >>>>>> >>>>>> https://archive.org/details/roff_manual From cmhanson at eschatologist.net Sun Jul 28 07:10:45 2024 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 27 Jul 2024 14:10:45 -0700 Subject: [COFF] Commodity hardware for paper terminal experience In-Reply-To: <20240717202057.f2a08545382ee5a9b64fe85d@sjmulder.nl> References: <20240717202057.f2a08545382ee5a9b64fe85d@sjmulder.nl> Message-ID: <2F006609-6313-48C6-B631-2E0DECF731F3@eschatologist.net> On Jul 17, 2024, at 11:20 AM, Sijmen J. Mulder wrote: > > I'd like to try replicating the experience more closely but I'm not > interested in acquiring collector's items or complex mechanical > hardware. Are you sure? :) A DECwriter IV or a DEC Correspondent makes for a *great* printing terminal about the size of an old-style electric typewriter, and ribbons are still available for them. (One of their advantages is that they’re impact printers that use plain paper and an inked ribbon. Though it’s not like thermal FAX paper such as the portable Silent 700 uses is hard to come by…) They’re still large and somewhat complex mechanical hardware, but they’re at least desktop-sized rather than floor-standing, and the Correspondent is even “portable…” I was actually going to take my Correspondent to Toorcamp this year, before I realized I didn’t have a new ribbon for it and my old one was out. You could probably also throw together something with an Arduino or Raspberry Pi, a serial printer, and a PS/2 keyboard to get the feel of a printing terminal. It’d probably be a fun and straightforward project, too since it’s just a couple of serial ports and a state machine, and you could make it as simple or featureful as you want. -- Chris From cmhanson at eschatologist.net Sun Jul 28 07:18:54 2024 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 27 Jul 2024 14:18:54 -0700 Subject: [COFF] More LCM fallout In-Reply-To: <20240713131716.A741818C075@mercury.lcs.mit.edu> References: <20240713131716.A741818C075@mercury.lcs.mit.edu> Message-ID: <21DB8095-4D00-42ED-891E-CA3BDBE5CB23@eschatologist.net> On Jul 13, 2024, at 6:17 AM, Noel Chiappa wrote: > > I wonder what will happen to all such material at the LCM. Anyone know? Having talked to some folks close to this, my understanding is that what’s being auctioned off are pieces from Paul Allen’s *personal* collection, some (or all?) of which were *on loan* to the LCM. My understanding is that the LCM’s own collection is *not* being auctioned off, but is instead part of the package for whoever acquires the museum as a whole. -- Chris From aki at insinga.com Mon Jul 29 04:04:27 2024 From: aki at insinga.com (Aron Insinga) Date: Sun, 28 Jul 2024 14:04:27 -0400 Subject: [COFF] More LCM fallout In-Reply-To: <21DB8095-4D00-42ED-891E-CA3BDBE5CB23@eschatologist.net> References: <20240713131716.A741818C075@mercury.lcs.mit.edu> <21DB8095-4D00-42ED-891E-CA3BDBE5CB23@eschatologist.net> Message-ID: <6f445be5-cde8-4f22-9b59-a43d3429a495@insinga.com> How is the LCM not part of his personal collection?  It's part of his estate.  IIUC he had not created and transferred it to another legal entity.  (I wish he had, but....) On 7/27/24 17:18, Chris Hanson wrote: > On Jul 13, 2024, at 6:17 AM, Noel Chiappa wrote: >> I wonder what will happen to all such material at the LCM. Anyone know? > Having talked to some folks close to this, my understanding is that what’s being auctioned off are pieces from Paul Allen’s *personal* collection, some (or all?) of which were *on loan* to the LCM. > > My understanding is that the LCM’s own collection is *not* being auctioned off, but is instead part of the package for whoever acquires the museum as a whole. > > -- Chris > From charles.unix.pro at gmail.com Mon Jul 29 13:14:51 2024 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sun, 28 Jul 2024 20:14:51 -0700 Subject: [COFF] More LCM fallout In-Reply-To: <6f445be5-cde8-4f22-9b59-a43d3429a495@insinga.com> References: <20240713131716.A741818C075@mercury.lcs.mit.edu> <21DB8095-4D00-42ED-891E-CA3BDBE5CB23@eschatologist.net> <6f445be5-cde8-4f22-9b59-a43d3429a495@insinga.com> Message-ID: The Multics tapes, documentation and the 6180 maintenance panel have been transferred to SDF, a Seattle area computing nonprofit. https://sdf.org/ The maintenance panel has been relocated to its new home, and is up and running and online. (I went and visited it today.) -- Charles On Sun, Jul 28, 2024, 11:10 AM Aron Insinga wrote: > How is the LCM not part of his personal collection? It's part of his > estate. IIUC he had not created and transferred it to another legal > entity. (I wish he had, but....) > > > On 7/27/24 17:18, Chris Hanson wrote: > > On Jul 13, 2024, at 6:17 AM, Noel Chiappa > wrote: > >> I wonder what will happen to all such material at the LCM. Anyone know? > > Having talked to some folks close to this, my understanding is that > what’s being auctioned off are pieces from Paul Allen’s *personal* > collection, some (or all?) of which were *on loan* to the LCM. > > > > My understanding is that the LCM’s own collection is *not* being > auctioned off, but is instead part of the package for whoever acquires the > museum as a whole. > > > > -- Chris > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: