I am looking for information on the history and development of ISAs as a
technology. Including:

- Why were they invented? (IBM wanted to sell their customers hardware
upgrades without requiring that they rewrite their code?)

- What was early sentiment towards them like? (From users, from
compiler-writers, from other CPU designers...)

- What was their adoption story like? How long did it take before they were
basically totally ubiquitous, as today?

- What were the _social_ factors that caused GPUs to expose primarily
higher-level interfaces, leaving the lower-level ones unstable and mostly
unused, unlike CPUs?

Any pointers?

Elijah Stone <elronnd@elronnd.net> wrote:
> I am looking for information on the history and development of ISAs as a
> technology. Including:
>
> - Why were they invented? (IBM wanted to sell their customers hardware
> upgrades without requiring that they rewrite their code?)

I think this is slightly the wrong question. Every stored program computer
has an ISA, being the encoding of stored instructions to logical operations.
In the early days the ISA was unique to the machine, but the machines
started as one-offs anyway.

What you're talking about is the split between architecture (the
specification that describes the programmer-facing model) and
microarchitecture (how the architecture is realised in a particular instance
of the machine, in terms of its design). The ISA is one feature of the
architecture, but not the only one - eg the memory model is another
architectural feature.

The general principles existed from the beginning, but not the clear
separation. IBM in the System/360 implemented a single architecture via
different microarchitectures. I'm not sure if they were the first.

Perhaps the question is more about the development process: first design a
specification for how the programming model would look. Then hand it over
to somebody to design implementation(s). Oftentimes those two would be the
same people, resulting in mixed up architectures, or optimised for a
specific set of implementation conditions. That happens when the team or
budget is small - even in the mid 80s the 32-bit ARM was designed this way.

> - What was early sentiment towards them like? (From users, from
> compiler-writers, from other CPU designers...)
>
> - What was their adoption story like? How long did it take before they were
> basically totally ubiquitous, as today?

Assuming you're talking about the fixed architectural specifications, it's
still common to build your own ISA for a special purpose machine. That is
typically deeply embedded so it is not publically-visible, but it's there.

RISC-V makes some effort to embrace this with its support for architectural
extensions: rather than doing you own entirely custom architecture, you can
still do it but use their boring baseline (add/sub/load/store/etc) instead
of rolling your own. But there is still a lot of rolling your own going on,
especially for things which aren't intended to run traditional software.

> - What were the _social_ factors that caused GPUs to expose primarily
> higher-level interfaces, leaving the lower-level ones unstable and mostly
> unused, unlike CPUs?

GPUs were not originally general purpose machines, they started off being
for graphics. Hence the various APIs like DirectX and OpenGL built up which
abstracted away the GPU as a processor - the application makes an OpenGL
call to a large piece of CPU-side software (called the 'driver', with
userspace and kernel parts) that 'does something' using the GPU to make it
happen - the 'something' is entirely opaque to the programmer. This model
allowed vendors to radically change how the 'something' worked behind the
scenes (multiple times), from fixed-function pipelines (not Turing complete)
through to SIMT processors.

Latterly vendors have exposed more 'processor' like APIs (CUDA, OpenCL) that
expose more of the SIMT side of things to the programmer. But that's
because they started off not exposing the programmer to the archiecture,
just to the API, and so they don't want software to hard code the
architecture.

(a fun alternative here was Intel's Larrabee/Xeon Phi, where they raided
their dusty chest of blueprints and produced a chip with lots of tiny
Pentium1 CPUs on it. There the architecture was fixed into the programming
model. It didn't do well, although not entirely due to this choice)

Another driving factor here is that CPUs are now fast enough to do
compilation of the GPU code at runtime. Because we don't know what specific
GPU the application will be running on ahead of time, the driver may contain
a full compiler (eg LLVM) that takes the application's code (in an
architecture-neutral format, not necessarily source code) and compiles it
for the specific GPU we have in the system. Because we don't need to ship a
precompiled binary, this allows more flexibility in that the newly-released
N+1th generation of GPU may have a completely different architecture to the
Nth.

Theo

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>
> GPUs were not originally general purpose machines, they started off being
> for graphics. Hence the various APIs like DirectX and OpenGL built up which
> abstracted away the GPU as a processor - the application makes an OpenGL
> call to a large piece of CPU-side software (called the 'driver', with
> userspace and kernel parts) that 'does something' using the GPU to make it
> happen - the 'something' is entirely opaque to the programmer. This model
> allowed vendors to radically change how the 'something' worked behind the
> scenes (multiple times), from fixed-function pipelines (not Turing complete)
> through to SIMT processors.
>
> Latterly vendors have exposed more 'processor' like APIs (CUDA, OpenCL) that
> expose more of the SIMT side of things to the programmer. But that's
> because they started off not exposing the programmer to the archiecture,
> just to the API, and so they don't want software to hard code the
> architecture.
>
> (a fun alternative here was Intel's Larrabee/Xeon Phi, where they raided
> their dusty chest of blueprints and produced a chip with lots of tiny
> Pentium1 CPUs on it. There the architecture was fixed into the programming
> model. It didn't do well, although not entirely due to this choice)
>
> Another driving factor here is that CPUs are now fast enough to do
> compilation of the GPU code at runtime. Because we don't know what specific
> GPU the application will be running on ahead of time, the driver may contain
> a full compiler (eg LLVM) that takes the application's code (in an
> architecture-neutral format, not necessarily source code) and compiles it
> for the specific GPU we have in the system. Because we don't need to ship a
> precompiled binary, this allows more flexibility in that the newly-released
> N+1th generation of GPU may have a completely different architecture to the
> Nth.
>

This always was a terrible model. For a long time it hindered development
of open source drivers for GPUs, leaving only (ugh!) Windows having drivers
that supported all the features. I don’t really follow the situation that
closely, my impression is that this has gotten a lot better but is still
not perfect. GPU designers really need to open up their specs.

--
Pete

Elijah Stone <elronnd@elronnd.net> writes:
>I am looking for information on the history and development of ISAs as a
>technology. Including:
>
>- Why were they invented? (IBM wanted to sell their customers hardware
>upgrades without requiring that they rewrite their code?)
>
>- What was early sentiment towards them like? (From users, from
>compiler-writers, from other CPU designers...)
>
>- What was their adoption story like? How long did it take before they were
>basically totally ubiquitous, as today?
>
>- What were the _social_ factors that caused GPUs to expose primarily
>higher-level interfaces, leaving the lower-level ones unstable and mostly
>unused, unlike CPUs?
>
>Any pointers?

comp.arch may be a better usenet newsgroup for this topic.

Generally your inquiry is very, very wide-ranging, and must start
with the earliest digital computers.

As a start, in early machines (late 50's), the term 'instruction'
hadn't yet become common - they used the term 'order' instead. Even
into the 90's, the processor instruction verification suite at
Burroughs was called "all-orders".

On Thu, 31 Aug 2023 14:34:55 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> As a start, in early machines (late 50's), the term 'instruction'
> hadn't yet become common - they used the term 'order' instead. Even
> into the 90's, the processor instruction verification suite at
> Burroughs was called "all-orders".

The French word for computer is ordinateur.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Peter Flass <peter_flass@yahoo.com> wrote:
> This always was a terrible model. For a long time it hindered development
> of open source drivers for GPUs, leaving only (ugh!) Windows having drivers
> that supported all the features. I don’t really follow the situation that
> closely, my impression is that this has gotten a lot better but is still
> not perfect. GPU designers really need to open up their specs.

I would partially disagree: the open source drivers that exist today are
mostly first-party drivers. In other words AMD wrote their driver and chose
to open source it. The GPU is complex enough that it's the most efficient
way to do it - the team who writes the driver has access to the hardware
source code, which the community doesn't have.

In general no devices have complete enough documentation to write full
third-party drivers, because writing that documentation is very expensive
and the audience for that documentation is very small (just the handful of
driver writers). Intel is probably best at this, but their documentation is
targeted specifically at open source driver writers (and so there may be
things missing that are used by eg the Windows driver).

There are a few third party drivers based on reverse engineering (nouveau
for Nvidia, Asahi Linux's Apple Silicon GPU driver). They are at best
partial implementations. It's amazing they exist, but better would have
been for nvidia or Apple to open source their first-party code.

If you decide that GPUs should conform to an stable architectural model,
like CPUs do, you are leaving a lot of performance on the table. We
wouldn't have the GPUs of today if they were still the same architectures of
decades ago (GPGPU compute wouldn't even be a thing).

Theo

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> This always was a terrible model. For a long time it hindered development
>> of open source drivers for GPUs, leaving only (ugh!) Windows having drivers
>> that supported all the features. I don’t really follow the situation that
>> closely, my impression is that this has gotten a lot better but is still
>> not perfect. GPU designers really need to open up their specs.
>
> I would partially disagree: the open source drivers that exist today are
> mostly first-party drivers. In other words AMD wrote their driver and chose
> to open source it. The GPU is complex enough that it's the most efficient
> way to do it - the team who writes the driver has access to the hardware
> source code, which the community doesn't have.
>
> In general no devices have complete enough documentation to write full
> third-party drivers, because writing that documentation is very expensive
> and the audience for that documentation is very small (just the handful of
> driver writers). Intel is probably best at this, but their documentation is
> targeted specifically at open source driver writers (and so there may be
> things missing that are used by eg the Windows driver).
>
> There are a few third party drivers based on reverse engineering (nouveau
> for Nvidia, Asahi Linux's Apple Silicon GPU driver). They are at best
> partial implementations. It's amazing they exist, but better would have
> been for nvidia or Apple to open source their first-party code.
>
> If you decide that GPUs should conform to an stable architectural model,
> like CPUs do, you are leaving a lot of performance on the table. We
> wouldn't have the GPUs of today if they were still the same architectures of
> decades ago (GPGPU compute wouldn't even be a thing).
>
> Theo
>

I don’t claim to be a hardware expert, but it seems to me that graphics
architecture is analogous to other computer architecture, at a higher
level. Computer ISA’s have primitives like load, or, add, subtract, etc.
Graphics primitives are things like draw a line, draw a solid, rotate an
image, etc. Just like mainframes are microprogrammed, the graphics chip
could be microprogrammed and expose the high-level functions to the driver.
This leaves lots of room for optimization in the microcode while presenting
a stable interface to the outside world. Maybe this is a hopelessly naive
idea.

--
Pete

It appears that Elijah Stone <elronnd@elronnd.net> said:
>I am looking for information on the history and development of ISAs as a
>technology. Including:
>
>- Why were they invented? (IBM wanted to sell their customers hardware
>upgrades without requiring that they rewrite their code?)

As others have noted, it sounds like you mean computer architecture, not ISA.

In the early 1950s it was a miracle when computers worked at all, and
programs had to be written to work around hardware bugs and
idiosyncracies. I heard of a machine where you couldn't have too many
"1" bits in any word because the voltage in the Williams tubes used
for main memory wasn't strong enough.

I'd say the IBM 704 in 1954 was the first computer that really worked.
It had core memory so you didn't have to worry about bit patterns and
a conservative tube design that would run programs reliably for hours
at a time which in that era was a big deal. It also had hardware
floating point and high quality peripheral devices adapted from IBMs
card equipment. People wrote a lot of software for it, including
the first Fortran compiler and a lot of Fortran programs. The next
machine, the 709, had a superset of the 704's ISA so it could run the
same software, the 7090 was a faster transistor version of the 709, and
so forth. They also had some decimal business machines starting with
the 702 and 705. One time they came out with a new business machine
which was faster and better but incompatible with the previous ones,
the customers said Nope, and they quickly came up with a compatible
upgrade. They also had a small business line, the 1400, and small
scientific 1620.

By 1960 it was well established that software was a big investment,
and it was important that new compters run existing software, and it
was increasingly expensive for computer makers to maintain multiple
product lines so everyone could upgrade. IBM then bet the company on
System 360, which was the first design where they started with the
archictecture and then built multiple implementaions that ran faster
or slower and could have larger or smaller memory. This is the classic
article:

https://www.researchgate.net/publication/220498837_Architecture_of_the_IBM_System360

The 360 wasn't compatible with any of the older machines but they made
a bet, which turned out to be a good one, that they could get people
to convert once in return for the promise that the 360 architecture
would last forever so they wouldn't have to convert again even as they
moved to larger or smaller models. (This was true, modern zSeries
mainframes still run S/360 code.) They also hedged their bets a
little; all but the fastest 360s were microprogrammed, and they
offered microcode compatibility packages. If, for example, you had a
360/65, you could boot it up in 7094 mode and it would run 70x code
faster than any real 70x machine until you finished rewriting or
recompiling your programs into 360 code.

The plan was also that there would be one operating system and one set
of applications but that failed because the OS/360 operating system
turned out to be way too big to run on the smaller machines. So they
quickly came up with cut down systems DOS and TOS (Disk and Tape) and
very simple BOS (Basic). That turned out to be OK, too. OS and DOS are
still around in greatly evolved form, and still run OS and DOS code
from the 1960s.

The 360 was such a great success that we now often forget how
revolutionary it was. It was not only the first architecture intended
from the outset to have multiple implmementations, but it was also the
first one with 8 bit bytes and the kind of byte addressing that is now
used everywhere, and the first popular machine with a large regular
set of registers.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sat, 2 Sep 2023 02:35:11 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> It appears that Elijah Stone <elronnd@elronnd.net> said:
> >I am looking for information on the history and development of ISAs as a
> >technology. Including:
> >
> >- Why were they invented? (IBM wanted to sell their customers hardware
> >upgrades without requiring that they rewrite their code?)
>
> As others have noted, it sounds like you mean computer architecture, not ISA.
>
> In the early 1950s it was a miracle when computers worked at all, and
> programs had to be written to work around hardware bugs and
> idiosyncracies. I heard of a machine where you couldn't have too many
> "1" bits in any word because the voltage in the Williams tubes used
> for main memory wasn't strong enough.
>
> I'd say the IBM 704 in 1954 was the first computer that really worked.
> It had core memory so you didn't have to worry about bit patterns and
> a conservative tube design that would run programs reliably for hours
> at a time which in that era was a big deal. It also had hardware
> floating point and high quality peripheral devices adapted from IBMs
> card equipment. People wrote a lot of software for it, including
> the first Fortran compiler and a lot of Fortran programs. The next
> machine, the 709, had a superset of the 704's ISA so it could run the
> same software, the 7090 was a faster transistor version of the 709, and
> so forth. They also had some decimal business machines starting with
> the 702 and 705. One time they came out with a new business machine
> which was faster and better but incompatible with the previous ones,
> the customers said Nope, and they quickly came up with a compatible
> upgrade. They also had a small business line, the 1400, and small
> scientific 1620.
>
> By 1960 it was well established that software was a big investment,
> and it was important that new compters run existing software, and it
> was increasingly expensive for computer makers to maintain multiple
> product lines so everyone could upgrade. IBM then bet the company on
> System 360, which was the first design where they started with the
> archictecture and then built multiple implementaions that ran faster
> or slower and could have larger or smaller memory. This is the classic
> article:
>
> https://www.researchgate.net/publication/220498837_Architecture_of_the_IBM_System360
>
> The 360 wasn't compatible with any of the older machines but they made
> a bet, which turned out to be a good one, that they could get people
> to convert once in return for the promise that the 360 architecture
> would last forever so they wouldn't have to convert again even as they
> moved to larger or smaller models. (This was true, modern zSeries
> mainframes still run S/360 code.) They also hedged their bets a
> little; all but the fastest 360s were microprogrammed, and they
> offered microcode compatibility packages. If, for example, you had a
> 360/65, you could boot it up in 7094 mode and it would run 70x code
> faster than any real 70x machine until you finished rewriting or
> recompiling your programs into 360 code.
>
> The plan was also that there would be one operating system and one set
> of applications but that failed because the OS/360 operating system
> turned out to be way too big to run on the smaller machines. So they
> quickly came up with cut down systems DOS and TOS (Disk and Tape) and
> very simple BOS (Basic). That turned out to be OK, too. OS and DOS are
> still around in greatly evolved form, and still run OS and DOS code
> from the 1960s.
>
> The 360 was such a great success that we now often forget how
> revolutionary it was. It was not only the first architecture intended
> from the outset to have multiple implmementations, but it was also the
> first one with 8 bit bytes and the kind of byte addressing that is now
> used everywhere, and the first popular machine with a large regular
> set of registers.

I'm sure the Wheelers will be along shortly to tell of their involvement.
- a Big Thing that you omitted about the 360 was the invention?/use of VM.

> --
> Regards,
> John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

--
Bah, and indeed Humbug.

On Sat, 2 Sep 2023 09:53:51 +0100
"Kerr-Mudd, John" <admin@127.0.0.1> wrote:

[]
>
> I'm sure the Wheelers will be along shortly to tell of their involvement.
> - a Big Thing that you omitted about the 360 was the invention?/use of VM.
>
>
Oh dear, Lynn Wheeler last posted back in April, without Anne.

--
Bah, and indeed Humbug.

According to Kerr-Mudd, John <admin@127.0.0.1>:
>> The 360 was such a great success that we now often forget how
>> revolutionary it was. It was not only the first architecture intended
>> from the outset to have multiple implmementations, but it was also the
>> first one with 8 bit bytes and the kind of byte addressing that is now
>> used everywhere, and the first popular machine with a large regular
>> set of registers.
>
>I'm sure the Wheelers will be along shortly to tell of their involvement.
>- a Big Thing that you omitted about the 360 was the invention?/use of VM.

Virtualization was an benefit of the 360's well defined architecture,
probably an accidental one. There was a clear spec for everything from
how you boostrap, er, IPL your system to how you send commands to I/O
devices, how they send replies, and how they interrupt. So they
implemented that spec in software and whaddya know, it worked.

By the way, on Lynn's web site it says he's been posting like crazy on
Facebook in the past month, but I haven't checked.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
> By the way, on Lynn's web site it says he's been posting like crazy on
> Facebook in the past month, but I haven't checked.

well, lots of (facebook) 360, 360/30, 360/65, 360/mp, 360/67 (& couple
other things) ... some repeated in different groups
http://www.garlic.com/~lynn/2023e.html

--
virtualization experience starting Jan1968, online at home since Mar1970

On Sat, 2 Sep 2023 09:57:51 +0100
"Kerr-Mudd, John" <admin@127.0.0.1> wrote:

> On Sat, 2 Sep 2023 09:53:51 +0100
> "Kerr-Mudd, John" <admin@127.0.0.1> wrote:

> Oh dear, Lynn Wheeler last posted back in April, without Anne.

Indeed I had been noticing Lynn's absence.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

John Levine <johnl@taugh.com> schrieb:

> The 360 was such a great success that we now often forget how
> revolutionary it was. It was not only the first architecture intended
> from the outset to have multiple implmementations, but it was also the
> first one with 8 bit bytes and the kind of byte addressing that is now
> used everywhere, and the first popular machine with a large regular
> set of registers.

The PDP-6 had something close to 16 registers in its lowest 16
words of memory, but I guess it is possible to argue that it
wasn't very popular (but the PDP-10 later was), and that these
memory locations were not really registers; if I read correctly,
it was possible to put code into them and run it.

On 2023-09-04 13:02, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>
>> The 360 was such a great success that we now often forget how
>> revolutionary it was. It was not only the first architecture intended
>> from the outset to have multiple implmementations, but it was also the
>> first one with 8 bit bytes and the kind of byte addressing that is now
>> used everywhere, and the first popular machine with a large regular
>> set of registers.
>
> The PDP-6 had something close to 16 registers in its lowest 16
> words of memory, but I guess it is possible to argue that it
> wasn't very popular (but the PDP-10 later was), and that these
> memory locations were not really registers; if I read correctly,
> it was possible to put code into them and run it.

Good points.
Definitely 16 registers, and yes, I would definitely call them
registers. The fact that they exist in memory space isn't that
important, nor that you could run code in them. They were treated
specially by the instructions.

And the PDP-6 was before the S/360. But it's also worth noting that the
PDP-6 (and descendants) are a computer architecture that have now been
dead for over 30 years.

The PDP-11 (at least some models) have the exact same behavior with the
registers. The CPU registers do exist in memory space, and you can run
code in them.

Johnny

In article <Qtj*FTbpz@news.chiark.greenend.org.uk>,
theom+news@chiark.greenend.org.uk (Theo Markettos) wrote:

> (a fun alternative here was Intel's Larrabee/Xeon Phi, where they
> raided their dusty chest of blueprints and produced a chip with
> lots of tiny Pentium1 CPUs on it. There the architecture was fixed
> into the programming model. It didn't do well, although not entirely
> due to this choice)

They wanted to solve the GPU programming problem by applying an existing
ISA. It might have gone better had they been able to write software that
made it an effective GPU, but Intel were unable to do that. They tried to
sell it as a CPU offload system, but its old-fashioned floating point and
limited access to memory doomed that, too.

John

On 04/09/2023 14:43, Johnny Billquist wrote:
>
> Good points.
> Definitely 16 registers, and yes, I would definitely call them
> registers. The fact that they exist in memory space isn't that
> important, nor that you could run code in them. They were treated
> specially by the instructions.
>
> And the PDP-6 was before the S/360. But it's also worth noting that the
> PDP-6 (and descendants) are a computer architecture that have now been
> dead for over 30 years.
>
> The PDP-11 (at least some models) have the exact same behavior with the
> registers. The CPU registers do exist in memory space, and you can run
> code in them.

I've always assumed that the registers were _saved_ into memory space
when the process was stopped.

The main point on a PDP10 of putting code into the registers was that it
went a lot faster - no memory access required.

Andy

On Mon, 4 Sep 2023 16:36:54 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The main point on a PDP10 of putting code into the registers was that it
> went a lot faster - no memory access required.

The TI 990/9900 series of machines had the general purpose registers
in memory pointed to by a CPU based register - context switching simply
involved pointing at a different bit of memory to get a new set of
registers. It made for very fast context switching and slow register
operations - an interesting trade off.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem A Rivet's Shot <steveo@eircom.net> schrieb:
> On Mon, 4 Sep 2023 16:36:54 +0100
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> The main point on a PDP10 of putting code into the registers was that it
>> went a lot faster - no memory access required.
>
> The TI 990/9900 series of machines had the general purpose registers
> in memory pointed to by a CPU based register - context switching simply
> involved pointing at a different bit of memory to get a new set of
> registers. It made for very fast context switching and slow register
> operations - an interesting trade off.

Or subroutine calls...

In the age of the 6502, when memory ran twice as fast as the CPU, this
was feasible. Not so much nowadays, where you can wait 150 cycles for
a main memory access.

On 2023-09-04 17:36, Vir Campestris wrote:
> On 04/09/2023 14:43, Johnny Billquist wrote:
>>
>> Good points.
>> Definitely 16 registers, and yes, I would definitely call them
>> registers. The fact that they exist in memory space isn't that
>> important, nor that you could run code in them. They were treated
>> specially by the instructions.
>>
>> And the PDP-6 was before the S/360. But it's also worth noting that
>> the PDP-6 (and descendants) are a computer architecture that have now
>> been dead for over 30 years.
>>
>> The PDP-11 (at least some models) have the exact same behavior with
>> the registers. The CPU registers do exist in memory space, and you can
>> run code in them.
>
> I've always assumed that the registers were _saved_ into memory space
> when the process was stopped.
>
> The main point on a PDP10 of putting code into the registers was that it
> went a lot faster - no memory access required.

As far as I know/can remember, there was the fast register option for
the KI10 (or was it KA?) which actually sat on top of the normal memory,
meaning the first 16 words of main memory was never used. And instead
you had some really fast memory there.

But if you didn't have it, then normal memory was used. With the KL and
KS I wouldn't know for sure. There is no obvious easy way to tell, I
think. But for the machine that had the fastmem option, it was fairly
obvious.

Johnny

On 2023-09-04 19:25, Johnny Billquist wrote:
> On 2023-09-04 17:36, Vir Campestris wrote:
>> On 04/09/2023 14:43, Johnny Billquist wrote:
>>>
>>> Good points.
>>> Definitely 16 registers, and yes, I would definitely call them
>>> registers. The fact that they exist in memory space isn't that
>>> important, nor that you could run code in them. They were treated
>>> specially by the instructions.
>>>
>>> And the PDP-6 was before the S/360. But it's also worth noting that
>>> the PDP-6 (and descendants) are a computer architecture that have now
>>> been dead for over 30 years.
>>>
>>> The PDP-11 (at least some models) have the exact same behavior with
>>> the registers. The CPU registers do exist in memory space, and you
>>> can run code in them.
>>
>> I've always assumed that the registers were _saved_ into memory space
>> when the process was stopped.
>>
>> The main point on a PDP10 of putting code into the registers was that
>> it went a lot faster - no memory access required.
>
> As far as I know/can remember, there was the fast register option for
> the KI10 (or was it KA?) which actually sat on top of the normal memory,
> meaning the first 16 words of main memory was never used. And instead
> you had some really fast memory there.
>
> But if you didn't have it, then normal memory was used. With the KL and
> KS I wouldn't know for sure. There is no obvious easy way to tell, I
> think. But for the machine that had the fastmem option, it was fairly
> obvious.

According to Wikipedia it was the KA10 that had the registers in memory,
and a fast register hardware option. All later models had the registers
in the CPU.

I guess that might imply that the PDP-6 also had the registers in main
memory.

Johnny

On Mon, 4 Sep 2023 17:09:29 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> schrieb:
> > On Mon, 4 Sep 2023 16:36:54 +0100
> > Vir Campestris <vir.campestris@invalid.invalid> wrote:
> >
> >> The main point on a PDP10 of putting code into the registers was that
> >> it went a lot faster - no memory access required.
> >
> > The TI 990/9900 series of machines had the general purpose
> > registers in memory pointed to by a CPU based register - context
> > switching simply involved pointing at a different bit of memory to get
> > a new set of registers. It made for very fast context switching and
> > slow register operations - an interesting trade off.
>
> Or subroutine calls...
>
> In the age of the 6502, when memory ran twice as fast as the CPU, this
> was feasible. Not so much nowadays, where you can wait 150 cycles for
> a main memory access.

I'd think L1 cache would work pretty well for the purpose and these
days there's more of that than main memory on many a 6502 based system.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Mon, 04 Sep 2023 16:36:54 +0100, Vir Campestris wrote:

> On 04/09/2023 14:43, Johnny Billquist wrote:
>>
>> Good points.
>> Definitely 16 registers, and yes, I would definitely call them
>> registers. The fact that they exist in memory space isn't that
>> important, nor that you could run code in them. They were treated
>> specially by the instructions.
>>
>> And the PDP-6 was before the S/360. But it's also worth noting that the
>> PDP-6 (and descendants) are a computer architecture that have now been
>> dead for over 30 years.
>>
>> The PDP-11 (at least some models) have the exact same behavior with the
>> registers. The CPU registers do exist in memory space, and you can run
>> code in them.
>
> I've always assumed that the registers were _saved_ into memory space
> when the process was stopped.

My understanding is that they were special-cased by the hardware. They
were real registers, but reference to addresses 0-15 got the register
instead of memory. Also, that low end models didn't have actual registers,
just memory.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

In article <20230904175846.74876eef530f19d9d2728dfa@eircom.net>,
steveo@eircom.net (Ahem A Rivet's Shot) wrote:

> The TI 990/9900 series of machines had the general purpose
> registers in memory pointed to by a CPU based register -
> context switching simply involved pointing at a different
> bit of memory to get a new set of registers. It made for
> very fast context switching and slow register operations
> - an interesting trade off.

They were originally designed as industrial controllers, for uses where
the computation load was pretty light, but response to interrupts had to
be fast. They had 256 "ordinary" interrupt levels, plus 8
special-priority levels.

John

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Mon, 4 Sep 2023 16:36:54 +0100
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> The main point on a PDP10 of putting code into the registers was that it
>> went a lot faster - no memory access required.
>
> The TI 990/9900 series of machines had the general purpose registers
> in memory pointed to by a CPU based register - context switching simply
> involved pointing at a different bit of memory to get a new set of
> registers. It made for very fast context switching and slow register
> operations - an interesting trade off.
>

GE 400 did this, but only with its one register.

--
Pete