Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?
       [not found]                 ` <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com>
@ 2024-07-08 22:14                   ` Paul Winalski
  2024-07-08 23:18                     ` segaloco via COFF
       [not found]                     ` <a231a9ad-b944-476c-b692-f092da2e76a2@insinga.com>
       [not found]                   ` <CACY3YMFNfX+Wh5W6pUK-YrLduwMjKLMLkxi8fprcO8=FkXwUUw@mail.gmail.com>
  1 sibling, 2 replies; 6+ messages in thread
From: Paul Winalski @ 2024-07-08 22:14 UTC (permalink / raw)
  To: Computer Old Farts Followers; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

[redirecting this to COFF]

On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki@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.

[-- Attachment #2: Type: text/html, Size: 4039 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [COFF] Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?
  2024-07-08 22:14                   ` [COFF] Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Paul Winalski
@ 2024-07-08 23:18                     ` segaloco via COFF
       [not found]                     ` <a231a9ad-b944-476c-b692-f092da2e76a2@insinga.com>
  1 sibling, 0 replies; 6+ messages in thread
From: segaloco via COFF @ 2024-07-08 23:18 UTC (permalink / raw)
  To: COFF

On Monday, July 8th, 2024 at 3:14 PM, Paul Winalski <paul.winalski@gmail.com> wrote:

> [redirecting this to COFF]
> 
> On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki@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_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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [COFF] Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?
       [not found]                     ` <a231a9ad-b944-476c-b692-f092da2e76a2@insinga.com>
@ 2024-07-09 17:18                       ` Paul Winalski
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Winalski @ 2024-07-09 17:18 UTC (permalink / raw)
  To: Aron Insinga; +Cc: Computer Old Farts Followers

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

On Mon, Jul 8, 2024 at 9:04 PM Aron Insinga <aki@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.

[-- Attachment #2: Type: text/html, Size: 3428 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [COFF] Data types in operating systems
       [not found]                         ` <c9cf756a-77ca-4341-b804-2b08f946dc68@insinga.com>
@ 2024-07-09 17:35                           ` Paul Winalski
  2024-07-09 17:46                             ` [COFF] " Dan Cross
  0 siblings, 1 reply; 6+ messages in thread
From: Paul Winalski @ 2024-07-09 17:35 UTC (permalink / raw)
  To: Computer Old Farts Followers

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1554 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [COFF] Re: Data types in operating systems
  2024-07-09 17:35                           ` [COFF] Data types in operating systems Paul Winalski
@ 2024-07-09 17:46                             ` Dan Cross
  2024-07-09 22:20                               ` Steffen Nurpmeso
  0 siblings, 1 reply; 6+ messages in thread
From: Dan Cross @ 2024-07-09 17:46 UTC (permalink / raw)
  To: Paul Winalski; +Cc: Computer Old Farts Followers

On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski <paul.winalski@gmail.com> 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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [COFF] Re: Data types in operating systems
  2024-07-09 17:46                             ` [COFF] " Dan Cross
@ 2024-07-09 22:20                               ` Steffen Nurpmeso
  0 siblings, 0 replies; 6+ messages in thread
From: Steffen Nurpmeso @ 2024-07-09 22:20 UTC (permalink / raw)
  To: Dan Cross; +Cc: Paul Winalski, Computer Old Farts Followers

Dan Cross wrote in
 <CAEoi9W5SepgWyepx2r7YJLA5AtAGgQdnFMgMEBXmxQHurcrSeA@mail.gmail.com>:
 |On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski <paul.winalski@gmail.com> \
 |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)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-07-09 22:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E6FF67D9-C833-443C-A939-277B95F7FFE8@gmail.com>
     [not found] ` <alpine.BSF.2.21.9999.2407051715510.72168@aneurin.horsfall.org>
     [not found]   ` <20240705213804.550128EDF53C@ary.qy>
     [not found]     ` <20240705214901.GR26356@mcvoy.com>
     [not found]       ` <20240705231714.5F0E58EE123E@ary.qy>
     [not found]         ` <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au>
     [not found]           ` <CAC20D2M9mvSWVqyMdLEco7LsivhkrBEentzs1Yezz_-GA+QN7Q@mail.gmail.com>
     [not found]             ` <6c797638-8fef-a587-0f73-cdb564568950@taugh.com>
     [not found]               ` <abe866a1-9b42-4f33-9007-38803a80a95f@technologists.com>
     [not found]                 ` <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com>
2024-07-08 22:14                   ` [COFF] Re: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Paul Winalski
2024-07-08 23:18                     ` segaloco via COFF
     [not found]                     ` <a231a9ad-b944-476c-b692-f092da2e76a2@insinga.com>
2024-07-09 17:18                       ` Paul Winalski
     [not found]                   ` <CACY3YMFNfX+Wh5W6pUK-YrLduwMjKLMLkxi8fprcO8=FkXwUUw@mail.gmail.com>
     [not found]                     ` <CAP2nic1gM_qxARYOt+ud5mac5uONrkp_sj1XeENpk3dp_8Ef_A@mail.gmail.com>
     [not found]                       ` <alpine.BSF.2.21.9999.2407091237590.6233@aneurin.horsfall.org>
     [not found]                         ` <c9cf756a-77ca-4341-b804-2b08f946dc68@insinga.com>
2024-07-09 17:35                           ` [COFF] Data types in operating systems Paul Winalski
2024-07-09 17:46                             ` [COFF] " Dan Cross
2024-07-09 22:20                               ` Steffen Nurpmeso

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).