From: Aron Insinga <aki@insinga.com>
To: Computer Old Farts Followers <coff@tuhs.org>
Subject: [COFF] Re: system implementation languages e.g. BLISS (was: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?)
Date: Fri, 12 Jul 2024 13:37:33 -0400 [thread overview]
Message-ID: <744f454d-36a3-4a76-a7fe-9934a77bd2a0@insinga.com> (raw)
In-Reply-To: <ce0380fd-ef36-4afe-99e1-92d8ebc4955a@insinga.com>
[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]
(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
[-- Attachment #2: Type: text/html, Size: 4019 bytes --]
next parent reply other threads:[~2024-07-12 17:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ce0380fd-ef36-4afe-99e1-92d8ebc4955a@insinga.com>
2024-07-12 17:37 ` Aron Insinga [this message]
2024-07-12 18:20 ` Paul Winalski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=744f454d-36a3-4a76-a7fe-9934a77bd2a0@insinga.com \
--to=aki@insinga.com \
--cc=coff@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).