- COFF - www.tuhs.org

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

by Aron Insinga

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

11 months, 4 weeks

2
1
0 0

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

by Dan Cross

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

11 months, 4 weeks

1
0
0 0

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

by segaloco

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

12 months

1
0
0 0

Reminder: use the right list

by Warren Toomey

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

12 months

1
0
0 0

Data types in operating systems

by Paul Winalski

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

12 months

3
2
0 0

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

by Paul Winalski

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

12 months

1
0
0 0

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

by Paul Winalski

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

12 months

2
1
0 0

Dan Murphy [Tenex Designer] Quote

by Clem Cole

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

1 year

2
2
0 0

Thank you all for your civility

by Warren Toomey

All, recently I saw on Bruce Schneier "Cryptogram" blog that he has had to change the moderation policy due to toxic comments: https://www.schneier.com/blog/archives/2024/06/new-blog-moderation-policy.h… So I want to take this opportunity to thank you all for your civility and respect for others on the TUHS and COFF lists. The recent systemd and make discussions have highlighted significant differences between people's experiences and opinions. Nonetheless, apart from a few pointed comments, the discussions have been polite and informative. These lists have been in use for decades now and, thankfully, I've only had to unsubscribe a handful of people for offensive behaviour. That's a testament to the calibre of people who are on the lists. Cheers and thank you again, Warren P.S. I'm a happy Devuan (non-systemd) user for many years now.

1 year

1
0
0 0

cmake (was: Version 256 of systemd boasts '42% less Unix) philosophy' The Register

by Greg 'groggy' Lehey

[Moved to COFF. Mercifully this really has nothing to do with Unix] On Wednesday, 19 June 2024 at 22:09:11 -0700, Luther Johnson wrote: > On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote: >> "Greg A. Woods" <woods(a)robohack.ca> wrote: >> >>> I will not ever allow cmake to run, or even exist, on the machines I >>> control... >> >> How do you deal with software that only builds with cmake (or meson, >> scons, ... whatever the developer decided to use as the build tool)? >> What alternatives exist short of reimplementing the build process in >> a standard makefile by hand, which is obviously very time consuming, >> error prone, and will probably break the next time you want to update >> a given package? >> >> If there is some great alternative, I would like to know about it. > > I just avoid tools that build with CMake altogether, I look for > alternative tools. The tool has already told me, what I can expect from > a continued relationship, by its use of CMake ... That's fine if you have the choice. I use Hugin (https://hugin.sourceforge.io/) a panorama stitcher, and the authors have made the decision to use cmake. I don't see any useful alternative to to Hugin, so I'm stuck with cmake. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF