10 Jul
2024
10 Jul
'24
8:34 p.m.
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.
I'm not sure what exactly you're referring to with "[t]hese
techniques"; I
gather you are talking about the low-level mechanisms used to implement
'system calls'? If so, please permit me to ramble for a while, and revise
your time-line somewhat.
There are two reasons one needs 'system calls'; low-level 'getting there
from
here' (which I'll explain below), and 'switching operating/protection
domains' (roughly, from 'user' to 'kernel').
In a batch OS which only runs in a single mode, one _could_ just use regular
subroutine calls to call the 'operating system', to 'get there from
here'.
The low-level reason not to do this is that one would need the addresses of
all the routines in the OS (which could change over time). If one instead
used permanent numbers to identify system calls, and had some sort of 'system
call' mechanism (an instruction - although it could be a subroutine call to a
fixed location in the OS), one wouldn't need the addresses. But this is just
low level mechanistic stuff. (I have yet to research to see if any early OS's
did use subroutine calls as their interface.)
The 'switching operating/protection domains' is more fundamental - and
unavoidable. Obviously, it wouldn't have been needed before there were
machines/OS's that operated in multiple modes. I don't have time to research
which was the _first_ machine/OS to need this, but clearly CTSS was an early
one. I happen to have a CTSS manual (two, actually :-), and in CTSS a system
call was:
TSX NAMEI, 4
..
..
NAMEI: TIA =HNAME
where 'NAME' "is the BCD name of a legitimate supervisor entry point",
and
the 'TIA' instruction may be "usefully (but inexactly) read as Trap Into A
core" (remember that in CTSS, the OS lived in the A core). (Don't ask me what
HNAME is, or what a TSX instruction does! :-)
So that would have been 1963, or a little earlier. By 1965 (see the 1965 Fall
Joint Computer Conference papers:
https://multicians.org/history.html
for more), MIT had already moved on to the idea of using a subroutine calls
that could cross protection domain boundaries for 'system calls', for
Multics. The advantage of doing that is that if the machine has a standard
way of passing arguments to subroutines, you natively/naturally get arguments
to system calls.
Noel
10 Jul
10 Jul
8:53 p.m.
New subject: machine code translation,as mental architecture models
On Wed, Jul 10, 2024 at 4:34 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
No, I was referring to the idea of binary transliteration from one
architecture to another. I found the reference; Knuth refers to "an
extreme example of inefficient use of computer simulators [... in] the
true story of machine A simulating machine B running a program that
simulates machine C! This is the way to make a large, expensive
computer give poorer results than its cheaper cousin." (This is on
page 203 of my copy of Volume 1.)
The idea of writing simulators for machines clearly dates to before
(or near) the beginning of TAOCP. The idea of binary instruction
translation during simulation is so obvious I can't imagine it wasn't
part of such simulations; particularly early on.
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.
I'm not sure what exactly you're referring to with "[t]hese
techniques"; I
gather you are talking about the low-level mechanisms used to implement
'system calls'? If so, please permit me to ramble for a while, and
revise
your time-line somewhat.
[snip]
(I have yet to research to see if any early OS's
did use subroutine calls as their interface.)
Not terribly early, but Xinu, as described in Comer's book, did/does.
[snip]
This was very interesting, regardless; thanks.
- Dan C.
10:29 p.m.
New subject: machine code translation,as mental architecture models
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.
Whirlwind, Summer 1954
http://bitsavers.org/pdf/mit/whirlwind/summer_session_1954
Summer Session Computer and Algebraic Systems were both
interpreters
11 p.m.
New subject: machine code translation,as mental architecture models
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.
11:14 p.m.
New subject: machine code translation,as mental architecture models
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:
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.
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.
9:26 p.m.
New subject: machine code translation,as mental architecture models
It appears that Noel Chiappa <jnc(a)mercury.lcs.mit.edu> said:
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.
We've been discussing batch or JIT translation of code which gives
much better performance without a lot of hardware help.
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. In a batch OS which only runs in a single mode, one
_could_ just use regular
subroutine calls to call the 'operating system', to 'get there from
here'.
The low-level reason not to do this is that one would need the addresses of
all the routines in the OS (which could change over time).
That was quite common. The manuals for 70xx IOCS, which was the I/O
management part of the system, show all the IOCS calls use TSX, the
usual subroutine call which saved the return address in an index
register and jumps (Transfers.) I think they avoided the address
problem by putting transfer vectors at fixed locations in low memory,
so your code did the TSX to an entry in the transfer vector which
jumped to the real routine.
one. I happen to have a CTSS manual (two, actually :-),
and in CTSS a system
call was:
TSX NAMEI, 4
..
..
NAMEI: TIA =HNAME
where 'NAME' "is the BCD name of a legitimate supervisor entry point",
and
the 'TIA' instruction may be "usefully (but inexactly) read as Trap Into A
core" (remember that in CTSS, the OS lived in the A core). (Don't ask me what
HNAME is, or what a TSX instruction does! :-)
TSX we know, but I don't see TIA in the regular 7094 manual. It's
documented in the RPQ for additional core storage, a jump from core
bank B to A. The multiprogramming RPQ made TIA trap in protection mode,
so it was indeed a system call.
11 Jul
11 Jul
1:29 a.m.
New subject: machine code translation,as mental architecture models
[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:
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.
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. 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.
58
days inactive
59
days old
6 comments
5 participants
participants (5)
-
Al Kossow -
Dan Cross -
jnc＠mercury.lcs.mit.edu -
John Levine -
segaloco