On Wednesday, August 10, 2022 at 10:22:54 PM UTC-6, Stephen Fuld wrote:

> Just a thought. Perhaps some time in the future, people will regard
> browsers having to sandbox things like Javascript the way we regard the
> Burroughs system having to sandbox C programs. Any architecture is
> designed based on what the architects see as current and predict will be
> future needs. Sometimes a new need arises that the architects didn't
> anticipate. :-(

I'm thinking of sandboxing JavaScript when it's in web sites I'm visiting.

If I have trusted JavaScript code, at least in the design I'm thinking of,
nothing would prevent it from being run on a JavaScript interpreter
running on the fast cores for trusted code instead.

Somehow, I don't think that in the future, letting just anyone run code
on your computer isn't going to be thought of as presenting security
issues. Even if they've come up with a nice neat solution to those
issues, unlike us.

John Savard

On Wednesday, August 10, 2022 at 8:42:43 PM UTC-6, MitchAlsup wrote:
> It is completely possible to design µprocessors that run fast
> and have none of these security flaws.

Maybe so. But is it possible to design them so that they don't
just "run fast" but "run just as fast" as ones that make use of
symmetric multi-threading, and an aggressive GBOoO model,
as opposed to restricting one's use of those techniques to safe
ones?

That being said, though, I'm not categorizing your efforts as of
no value. If an x86 could be implemented using the same techniques
as you intend to use for the My 66000... _then_ if that IS totally
secure against the Spectre family... great! Now I have something
faster than a 486 core to use for the untrusted code.

And if the difference really was so small that bothering with an
insecure core that goes all out for speed... doesn't gain much
speed... hey, that _would_ be even better. But I have my doubts
about whether you can get that far, from how you have described
your approach.

John Savard

On Thursday, August 11, 2022 at 1:50:08 AM UTC-6, Quadibloc wrote:
> On Wednesday, August 10, 2022 at 8:42:43 PM UTC-6, MitchAlsup wrote:
> > It is completely possible to design µprocessors that run fast
> > and have none of these security flaws.

> Maybe so. But is it possible to design them so that they don't
> just "run fast" but "run just as fast" as ones that make use of
> symmetric multi-threading, and an aggressive GBOoO model,
> as opposed to restricting one's use of those techniques to safe
> ones?

To avoid arguing in circles, I think I should clarify one other thing.

I do recognize that security is a *must*, while the highest possible
single-core speed is merely desirable. So if things got to the point
where the level of insecurity was intolerable, I'd be willing to switch
over to a My 66000 machine or a Mill machine. Others might be
a bit more suicidally foolish, and might take longer to convince.

I'm just saying that this kind of changeover will come very late
in the day... and so if there *is* a way to let people come closer
to having their cake and eating it too... it will get us out of the woods
much sooner.

John Savard

In article <7ffb3504-d68e-4cd7-82ce-96ef48744b78n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> I do recognize that security is a *must*, while the highest possible
> single-core speed is merely desirable. So if things got to the point
> where the level of insecurity was intolerable, I'd be willing to
> switch over to a My 66000 machine or a Mill machine. Others might be
> a bit more suicidally foolish, and might take longer to convince.

The difficulty is that while secure-execution designs are under
development, turning them into purchasable computers will take
significant amounts of time and money.

Since manufacturers are generally unwilling to change strategies until
the old one is definitely busted, the world may well find itself needing
to change architectures, but having nothing available to change to.

John

On Thursday, August 11, 2022 at 2:17:10 AM UTC-6, John Dallman wrote:

> The difficulty is that while secure-execution designs are under
> development, turning them into purchasable computers will take
> significant amounts of time and money.
>
> Since manufacturers are generally unwilling to change strategies until
> the old one is definitely busted, the world may well find itself needing
> to change architectures, but having nothing available to change to.

Since no reasonable Spectre-immune option is available for purchase
at the present time, the scenario you outline is very definitely a real
possibility. Although the issue is, I believe, in the microarchictecture and
not the ISA. Unless one has to have an architecture like the Mill that can
be fast without OoO. Apparently pulling Itanium off the shelf (as I had
previously suggested) is not an option, as it just isn't particularly fast.

But if Intel could "fix" Itanium by tweaking it somehow - certainly that
would get considered if the Mill came out and became a serious
competitive threat, but it should be considered much sooner than that -
I think it would be worth doing. Not that I think it is necessarily
possible, since the Itanium design is too closely tied to one particular
stage in the development of microcircuitry. Basically, Itanium exposes
its entire microarchitecture, so it's not something you can implement
in a different way to take advantage of being able to put more transistors
on a chip now.

The situation resulting from Russia's invasion of Ukraine ought to
lead to some *government* involvement in this matter.

As well, if Intel and AMD aren't taking this seriously - I think they are,
but within tight constraints the market is putting on them - IBM
would certainly be taking security seriously for its mainframes. If
there is an effective solution, they're well placed to find it.

Of course, given the significance of throughput in mainframe
applications, they could just go with costly mitigations that strip
out plenty of OoO features - and then increase the number of cores
to make up for it. I think that this is a strategy to which Mitch Alsup
has given some support. But while that could work for IBM, it
wouldn't for AMD and Intel: if they make chips like that, they just
won't sell.

John Savard

In article <a9f3c4cd-7709-4116-ba5b-f43eb5547265n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> Apparently pulling Itanium off the shelf (as I had previously
> suggested) is not an option, as it just isn't particularly fast.

Not in practice, no. It wasn't in 2003-05, when Itanium II appeared, and
it had less development than other architectures since then. It could be
fast back then, with hand-coded assembler, but compilers were unable to
extract much of that performance, and I doubt that problem has made much
progress. The architecture is quite unpleasant to work with, IME, and
since it was written off as a failure, nobody has had commercial
motivation to work on those compilers.

> But if Intel could "fix" Itanium by tweaking it somehow - certainly
> that would get considered if the Mill came out and became a serious
> competitive threat, but it should be considered much sooner than
> that - I think it would be worth doing. Not that I think it is
> necessarily possible, since the Itanium design is too closely tied
> to one particular stage in the development of microcircuitry.

That's part of it. The bulky instruction set is another significant
problem, since that demands larger caches than any other instruction set
I've seen. Here are some sizes, for a product I released in spring 2004,
from the same source on each platform. The product is libraries, and most
of what's in each package is the code, provided twice, as both archive
libraries and DLLs/Sharables.

Windows x86-64 78MB
Windows Itanium 140MB

HP-UX PA-RISC 64-bit 114MB
HP-UX Itanium 240MB

Solaris SPARC 64-bit 90MB
AIX POWER 64-bit 75MB

Trying to fix Itanium would involve re-designing it. Better to start
afresh.

John

On Wed, 10 Aug 2022 15:47:29 -0700, Stephen Fuld wrote:

> On 8/10/2022 2:47 PM, Quadibloc wrote:
>> On Wednesday, August 10, 2022 at 11:22:32 AM UTC-6, MitchAlsup wrote:
>>
>>> Boroughs had no cache, no branch prediction, and no OoO.
>>
>> Yes, that's true. But that doesn't mean that its approach to security
>> couldn't be applied to a CPU that had those things.
>>
>> Given, for example, that the GNU compiler suite supports multiple
>> languages by applying different front ends to a single back end,
>> presumably one could have a compiler that enforces security in the back
>> end so that one could still have other languages besides Algol on a
>> Burroughs-style system.
>>
>> Like Fortran or Pascal too. C might be too much to ask. (Or use a
>> different back end that restricts it to a sandbox, as the Burroughs
>> systems did to provide C.)
>
> Besides Algol, Burroughs provides trusted compilers for at least COBOL
> and Fortran.
>
> You are right that C's semantics make such guarantees impossible, so
> the Burroughs provided C compiler generated programs that run in a
> sandbox.
>
> But in order for a program to be a compiler (that is, generate approved
> object code), it required the approval of the operator/system
> administrator, so you couldn't just get some compiler off the web,
> modify the backend and expect it to be able to work.
>
> Note also that the Burroughs systems used tagged memory, so that might
> have made enforcing security easier.

There were also C compilers for Lisp Machines that presumably do similar
things to a Burroughs C compiler.

The source code for one of them is available if anyone wants to find out
how it mapped onto the VM provided by the machine.

Robert Swindells

On Thursday, August 11, 2022 at 5:17:15 AM UTC-6, John Dallman wrote:

> Trying to fix Itanium would involve re-designing it. Better to start
> afresh.

As it turns out, there is another option.

Well, maybe not.

The March 19, 1987 issue of _Electronics_ magazine promised,
on its cover, an article about the World's Fastest Microprocessor.

The article, beginning on page 61, was about the AMD Am29000
Streamlined Instruction Processor. It ran at all of 25 MHz. It required
a coprocessor, the Am29027, for floating-point in hardware.

Possibly that architecture, after being updated to 64 bits, could
serve as a sounder basis than the Itanium.

John Savard

On Thursday, August 11, 2022 at 8:25:39 AM UTC-6, Quadibloc wrote:

> The March 19, 1987 issue of _Electronics_ magazine promised,
> on its cover, an article about the World's Fastest Microprocessor.

However, it wasn't until November 1, 1995 that the Pentium Pro
was introduced. So that means that the Am29000 never had to
compete with an OoO processor - its pipeline was a classic
four-stage pipeline, fetch, decode, execute, write-back - and so
it is less clear if its features would be sufficient _to_ be competitive
with OoO. Although the article did claim that the Am29000 came
very close to achieving one instruction per cycle, with a cache for
branch addresses even overcoming the problems branches usually
cause.

Of course, "one instruction per cycle" sounds great, but one has to
also know how long a cycle is. That the chip ran at 25 MHz using
the technology of its day doesn't really answer that question; instead,
the figure that's needed to allow comparison across technologies
and process nodes is how many *gate delays* per cycle.

John Savard

On 8/11/2022 12:22 AM, Quadibloc wrote:
> On Wednesday, August 10, 2022 at 4:47:39 PM UTC-6, Stephen Fuld wrote:
>
>> But in order for a program to be a compiler (that is, generate approved
>> object code), it required the approval of the operator/system
>> administrator, so you couldn't just get some compiler off the web,
>> modify the backend and expect it to be able to work.
>
> I'm not proposing a solution for people using those computers.
>
> Even though there are some modern versions of them, mostly
> using emulation software running on x86 chips, still in service.
>
> I'm talking about home x86 desktop computers, where securing
> permission from a system operator is not an issue - and thus, of
> course, they're nakedly vulnerable to social engineering.
>
> So I'm wondering if, given some modified version of the chips
> used in home computers that has a better sandbox for untrusted
> code, Burroughs-style techniques might not have some role.

I am not sure what you want here. The Burroughs hardware, except for
the tagged memory, provided much less security than a current X86. All
the security (except tags) was due to restricting the software.

So what Burroughs-style techniques are you proposing?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 8/11/2022 7:46 AM, Quadibloc wrote:
> On Thursday, August 11, 2022 at 8:25:39 AM UTC-6, Quadibloc wrote:
>
>> The March 19, 1987 issue of _Electronics_ magazine promised,
>> on its cover, an article about the World's Fastest Microprocessor.
>
> However, it wasn't until November 1, 1995 that the Pentium Pro
> was introduced. So that means that the Am29000 never had to
> compete with an OoO processor - its pipeline was a classic
> four-stage pipeline, fetch, decode, execute, write-back - and so
> it is less clear if its features would be sufficient _to_ be competitive
> with OoO. Although the article did claim that the Am29000 came
> very close to achieving one instruction per cycle, with a cache for
> branch addresses even overcoming the problems branches usually
> cause.
>
> Of course, "one instruction per cycle" sounds great, but one has to
> also know how long a cycle is. That the chip ran at 25 MHz using
> the technology of its day doesn't really answer that question; instead,
> the figure that's needed to allow comparison across technologies
> and process nodes is how many *gate delays* per cycle.

We used the 29K for a project I worked on. It was quite nice. Note
that later versions included the FPU on die, and even went superscaler.
Unfortunately, AMD decided to kill the series to devote more engineering
resources the their X86 compatible products so we never used those
versions.

https://en.wikipedia.org/wiki/AMD_Am29000

Also note that even in the original 29000, there was limited OoO, as the
instructions after a load that didn't reference the load target register
could proceed while the load was in process. In practice, since the
chip included no cache, this was of limited value.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 8/10/2022 10:22 AM, MitchAlsup wrote:
> On Wednesday, August 10, 2022 at 3:48:46 AM UTC-5, Anton Ertl wrote:
>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>> The Burroughs systems certainly did have a unique take on security.
>>>
>>> And yet it _worked_ in practise.
> <
>> The Burroughs approach does not help against Spectre, while on the
>> contrary, MMU-based security helps to some extent.
> <
> Boroughs had no cache, no branch prediction, and no OoO.

Later versions of the hardware did have a cache, at least for the stack.

Also remember, hardware development for these systems stopped before
some of these techniques became popular.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 8/11/2022 7:57 AM, Stephen Fuld wrote:
> On 8/11/2022 12:22 AM, Quadibloc wrote:
>> On Wednesday, August 10, 2022 at 4:47:39 PM UTC-6, Stephen Fuld wrote:
>>
>>> But in order for a program to be a compiler (that is, generate approved
>>> object code), it required the approval of the operator/system
>>> administrator, so you couldn't just get some compiler off the web,
>>> modify the backend and expect it to be able to work.
>>
>> I'm not proposing a solution for people using those computers.
>>
>> Even though there are some modern versions of them, mostly
>> using emulation software running on x86 chips, still in service.
>>
>> I'm talking about home x86 desktop computers, where securing
>> permission from a system operator is not an issue - and thus, of
>> course, they're nakedly vulnerable to social engineering.
>>
>> So I'm wondering if, given some modified version of the chips
>> used in home computers that has a better sandbox for untrusted
>> code, Burroughs-style techniques might not have some role.
>
> I am not sure what you want here.  The Burroughs hardware, except for
> the tagged memory, provided much less security than a current X86.  All
> the security (except tags) was due to restricting the software.
>
> So what Burroughs-style techniques are you proposing?
>
>

I wrote the DCAlgol compiler for the B6500 Burroughs mainframe.

Yes, it did rely on system control and blessing of the compilers - as a
mainframe with human operators this was a reasonable choice of the day,
but was not forced by the architecture.

Memory access was not the reason Burroughs would be vulnerable in a Wild
West environment like C; tagging of the segmented architecture took care
of that nicely. The problem was the absence of supervisor-more
instructions. The ESPOL compiler used to write the MCP operating system
had available a few supervisor instructions (MSEQ, OVWR, HEYU, ???) that
you couldn't get from the Algol/COBOL/Fortran compilers used by
applications - but the binary of the apps from any of those compilers
were not architecturally restricted at run time. If you could introduce
any way to get an executable containing those instructions - by your own
compiler, say - then the system was yours.

Curing this would be straightforward: add a supervisor mode. Now you no
longer need to bless the compilers, you just need to bless the OS. Just
like every other system on earth must.

I don't know why there was no supervisor mode in the original design;
such issues went back to the predecessor B5000, and the KDF9 for that
matter. No mainframes of the day had them; it didn't become an issue
until the advent of time-sharing systems. However, I can speculate what
kind of trouble retrofitting a mode onto the machine would have.

The problem would be controlling how one entered S-mode. Assuming that
mode had function granularity, one could reserve a bit in the tag-7
thunk descriptor to indicate that the target should run in S-mode.
However, IIRC all bits in the descriptor were already used, which would
kill an address bit, cutting the available memory capacity of the
machine in half. Or one could add another tag to represent an S-mode
thunk, but all eight tag values were in use. I can understand why adding
S-mode made no business sense in mid-1960's.

Of course, the ISA ran out of address space within a decade anyway, and
had to go to double-wide descriptors, which would easily allow for a
mode bit. But by then there was customer lock-in, the chance was missed.

On 8/11/2022 8:38 AM, Ivan Godard wrote:
> On 8/11/2022 7:57 AM, Stephen Fuld wrote:
>> On 8/11/2022 12:22 AM, Quadibloc wrote:
>>> On Wednesday, August 10, 2022 at 4:47:39 PM UTC-6, Stephen Fuld wrote:
>>>
>>>> But in order for a program to be a compiler (that is, generate approved
>>>> object code), it required the approval of the operator/system
>>>> administrator, so you couldn't just get some compiler off the web,
>>>> modify the backend and expect it to be able to work.
>>>
>>> I'm not proposing a solution for people using those computers.
>>>
>>> Even though there are some modern versions of them, mostly
>>> using emulation software running on x86 chips, still in service.
>>>
>>> I'm talking about home x86 desktop computers, where securing
>>> permission from a system operator is not an issue - and thus, of
>>> course, they're nakedly vulnerable to social engineering.
>>>
>>> So I'm wondering if, given some modified version of the chips
>>> used in home computers that has a better sandbox for untrusted
>>> code, Burroughs-style techniques might not have some role.
>>
>> I am not sure what you want here.  The Burroughs hardware, except for
>> the tagged memory, provided much less security than a current X86.
>> All the security (except tags) was due to restricting the software.
>>
>> So what Burroughs-style techniques are you proposing?
>>
>>
>
> I wrote the DCAlgol compiler for the B6500 Burroughs mainframe.

I defer to your knowledge of these systems, however . . .

>
> Yes, it did rely on system control and blessing of the compilers - as a
> mainframe with human operators this was a reasonable choice of the day,
> but was not forced by the architecture.
>
> Memory access was not the reason Burroughs would be vulnerable in a Wild
> West environment like C; tagging of the segmented architecture took care
> of that nicely.

Then why did the Burroughs provided C compiler create sandboxed code?

> The problem was the absence of supervisor-more
> instructions.

I consider that to be part of the architecture. YMMV

> The ESPOL compiler used to write the MCP operating system
> had available a few supervisor instructions (MSEQ, OVWR, HEYU, ???) that
> you couldn't get from the Algol/COBOL/Fortran compilers used by
> applications - but the binary of the apps from any of those compilers
> were not architecturally restricted at run time. If you could introduce
> any way to get an executable containing those instructions - by your own
> compiler, say - then the system was yours.

Yes, apparently there was a bug such that a program could take a
checkpoint (back when such things made sense) to tape, take the tape to
another system, read in the image and modify the code to include
relevant supervisor instructions, then rewrite the tape, take it back to
the original system and restart the checkpoint. Obviously, this was fixed.

But you couldn't just get a compiler from anywhere, as in order to be
able to create a file marked in the file system as executable, the
compiler had to have the blessing of the operator.

> Curing this would be straightforward: add a supervisor mode. Now you no
> longer need to bless the compilers, you just need to bless the OS. Just
> like every other system on earth must.
>
> I don't know why there was no supervisor mode in the original design;
> such issues went back to the predecessor B5000, and the KDF9 for that
> matter. No mainframes of the day had them; it didn't become an issue
> until the advent of time-sharing systems.

Actually even multi-programming batch systems required protection. So
early competitors to the B5000 that supported multi-programming had a
supervisor mode. e.g. IBM S/360, Univac 1108, etc. Though perhaps they
were a little later than the B5000. I think the lack of supervisor mode
was just a design choice, but, as footnoted in the Wikipedia article
"There were security issues". :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 11 Aug 2022, Ivan Godard wrote
(in article <td37p0$27226$1@dont-email.me>):
> I don't know why there was no supervisor mode in the original design;
> such issues went back to the predecessor B5000, and the KDF9 for that
> matter. No mainframes of the day had them; it didn't become an issue
> until the advent of time-sharing systems. However, I can speculate what
> kind of trouble retrofitting a mode onto the machine would have.

?
KDF9 did have a supervisor mode.
It always was a timesharing (i.e. multiprogramming) system.

--
Bill Findlay

On 8/11/2022 9:30 AM, Stephen Fuld wrote:
> On 8/11/2022 8:38 AM, Ivan Godard wrote:
>> On 8/11/2022 7:57 AM, Stephen Fuld wrote:

snip

>> Memory access was not the reason Burroughs would be vulnerable in a
>> Wild West environment like C; tagging of the segmented architecture
>> took care of that nicely.
>
> Then why did the Burroughs provided C compiler create sandboxed code?

Sorry for the self follow up, but I seem to recall that C's requirement
of allowing arithmetic on pointers would break the tagging system, so
the C implementation used its own pointers, and thus wasn't protected by
the provided mechanisms.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, August 11, 2022 at 9:11:48 AM UTC-6, Stephen Fuld wrote:

> We used the 29K for a project I worked on. It was quite nice. Note
> that later versions included the FPU on die, and even went superscaler.

I looked up information about them.

Their top-of-the-line version, the Am29050-40GC still had a clock speed
of only 40 MHz. But it also had a maximum power dissipation of slightly
under 8 watts - still enough to slap a fan on it, but vastly different from
what today's CPUs require. However, CPU chips in smartphones can have
clock speeds of 1 GHz, so with today's technology, high speed doesn't
absolutely require excessive amounts of power, even if that's high, but not
competitive, speed.

John Savard

On Friday, August 12, 2022 at 12:16:22 AM UTC-6, Quadibloc wrote:
> On Thursday, August 11, 2022 at 9:11:48 AM UTC-6, Stephen Fuld wrote:
>
> > We used the 29K for a project I worked on. It was quite nice. Note
> > that later versions included the FPU on die, and even went superscaler.
> I looked up information about them.
>
> Their top-of-the-line version, the Am29050-40GC still had a clock speed
> of only 40 MHz. But it also had a maximum power dissipation of slightly
> under 8 watts - still enough to slap a fan on it, but vastly different from
> what today's CPUs require. However, CPU chips in smartphones can have
> clock speeds of 1 GHz, so with today's technology, high speed doesn't
> absolutely require excessive amounts of power, even if that's high, but not
> competitive, speed.

I see there's more to the story.

The Honeywell 29KII was derived from the 29050, and it, or descendants
of it, are used in a lot of aircraft electronics.

There were actually versions of the 29050 that went up to 100 MHz.

And the 29050 design was also used as the basis for the AMD K5 processor.
Early versions had bugs in branch prediction and the cache, but those were
sorted out.

Of course, though, it got supplanted by the K6, which wasn't designed within
AMD, but instead came from the NextGen Nx686.That processor, unlike the
K5, was the one that provided Intel with serious competition.

John Savard

On 8/11/2022 9:30 AM, Stephen Fuld wrote:
> On 8/11/2022 8:38 AM, Ivan Godard wrote:
>> On 8/11/2022 7:57 AM, Stephen Fuld wrote:
>>> On 8/11/2022 12:22 AM, Quadibloc wrote:
>>>> On Wednesday, August 10, 2022 at 4:47:39 PM UTC-6, Stephen Fuld wrote:
>>>>
>>>>> But in order for a program to be a compiler (that is, generate
>>>>> approved
>>>>> object code), it required the approval of the operator/system
>>>>> administrator, so you couldn't just get some compiler off the web,
>>>>> modify the backend and expect it to be able to work.
>>>>
>>>> I'm not proposing a solution for people using those computers.
>>>>
>>>> Even though there are some modern versions of them, mostly
>>>> using emulation software running on x86 chips, still in service.
>>>>
>>>> I'm talking about home x86 desktop computers, where securing
>>>> permission from a system operator is not an issue - and thus, of
>>>> course, they're nakedly vulnerable to social engineering.
>>>>
>>>> So I'm wondering if, given some modified version of the chips
>>>> used in home computers that has a better sandbox for untrusted
>>>> code, Burroughs-style techniques might not have some role.
>>>
>>> I am not sure what you want here.  The Burroughs hardware, except for
>>> the tagged memory, provided much less security than a current X86.
>>> All the security (except tags) was due to restricting the software.
>>>
>>> So what Burroughs-style techniques are you proposing?
>>>
>>>
>>
>> I wrote the DCAlgol compiler for the B6500 Burroughs mainframe.
>
> I defer to your knowledge of these systems, however . . .
>
>
>>
>> Yes, it did rely on system control and blessing of the compilers - as
>> a mainframe with human operators this was a reasonable choice of the
>> day, but was not forced by the architecture.
>>
>> Memory access was not the reason Burroughs would be vulnerable in a
>> Wild West environment like C; tagging of the segmented architecture
>> took care of that nicely.
>
> Then why did the Burroughs provided C compiler create sandboxed code?

Because of the representation of the IRW (Indirect Reference Word, i.e.
pointer - tag 3? I don't remember). The IRW was secure - you'd have to
use the OS OVWR (overwrite) op to change it, and that op would be in
S-mode if Burroughs had had one. Which means that there was no secure
way to arbitrarily increment the IRW as required by C. The solution they
came up with (after my time there) was a sandbox - you could use the
OVWR to stomp on your IRW, but the result was restricted to the sandbox
region.

Once the double-wide descriptors were added it was possible (and maybe
done, I don't know) to put bounds in the IRW, or an index into a
valid-segment array, or various other approaches. But all those would
have been incompatible extensions.

At heart the problem is that C *as it is used* is not compatible with a
segmented architecture. CHERI has a similar problem. It is true that the
formal definition is compatible - incrementing a pointer off the object
to which it points if formally Undefined Behavior, and a segment system
that throuws a SEGV is entirely correct. But code that violates that
standard is universal, and markets trump standards any day.

>
>
>> The problem was the absence of supervisor-more instructions.
>
> I consider that to be part of the architecture. YMMV

Of course.
>
>
>> The ESPOL compiler used to write the MCP operating system had
>> available a few supervisor instructions (MSEQ, OVWR, HEYU, ???) that
>> you couldn't get from the Algol/COBOL/Fortran compilers used by
>> applications - but the binary of the apps from any of those compilers
>> were not architecturally restricted at run time. If you could
>> introduce any way to get an executable containing those instructions -
>> by your own compiler, say - then the system was yours.
>
> Yes, apparently there was a bug such that a program could take a
> checkpoint (back when such things made sense) to tape, take the tape to
> another system, read in the image and modify the code to include
> relevant supervisor instructions, then rewrite the tape, take it back to
> the original system and restart the checkpoint.  Obviously, this was fixed.
>
> But you couldn't just get a compiler from anywhere, as in order to be
> able to create a file marked in the file system as executable, the
> compiler had to have the blessing of the operator.
>
>
>> Curing this would be straightforward: add a supervisor mode. Now you
>> no longer need to bless the compilers, you just need to bless the OS.
>> Just like every other system on earth must.
>>
>> I don't know why there was no supervisor mode in the original design;
>> such issues went back to the predecessor B5000, and the KDF9 for that
>> matter. No mainframes of the day had them; it didn't become an issue
>> until the advent of time-sharing systems.
>
> Actually even multi-programming batch systems required protection. So
> early competitors to the B5000 that supported multi-programming had a
> supervisor mode.  e.g. IBM S/360, Univac 1108, etc.  Though perhaps they
> were a little later than the B5000.  I think the lack of supervisor mode
> was just a design choice, but, as footnoted in the Wikipedia article
> "There were security issues".  :-)
>
>
>

On Friday, August 12, 2022 at 1:16:22 AM UTC-5, Quadibloc wrote:
> On Thursday, August 11, 2022 at 9:11:48 AM UTC-6, Stephen Fuld wrote:
>
> > We used the 29K for a project I worked on. It was quite nice. Note
> > that later versions included the FPU on die, and even went superscaler.
> I looked up information about them.
>
> Their top-of-the-line version, the Am29050-40GC still had a clock speed
> of only 40 MHz. But it also had a maximum power dissipation of slightly
> under 8 watts - still enough to slap a fan on it, but vastly different from
> what today's CPUs require. However, CPU chips in smartphones can have
> clock speeds of 1 GHz, so with today's technology, high speed doesn't
> absolutely require excessive amounts of power, even if that's high, but not
> competitive, speed.
<
Those chips in cell phones can reach their thermal limits in milliseconds, too.
>
> John Savard

On Friday, August 12, 2022 at 11:13:23 AM UTC-6, MitchAlsup wrote:
> On Friday, August 12, 2022 at 1:16:22 AM UTC-5, Quadibloc wrote:
> > On Thursday, August 11, 2022 at 9:11:48 AM UTC-6, Stephen Fuld wrote:
> >
> > > We used the 29K for a project I worked on. It was quite nice. Note
> > > that later versions included the FPU on die, and even went superscaler.
> > I looked up information about them.
> >
> > Their top-of-the-line version, the Am29050-40GC still had a clock speed
> > of only 40 MHz. But it also had a maximum power dissipation of slightly
> > under 8 watts - still enough to slap a fan on it, but vastly different from
> > what today's CPUs require. However, CPU chips in smartphones can have
> > clock speeds of 1 GHz, so with today's technology, high speed doesn't
> > absolutely require excessive amounts of power, even if that's high, but not
> > competitive, speed.
> <
> Those chips in cell phones can reach their thermal limits in milliseconds, too.

Unfortunately, that is quite true, and I did forget about it. However, running
just a single core at 500 MHz or something like that would still beat a 100 MHz
29050 - since I've now learned it later got up to that speed - and so the technology
has still improved somewhat. We can make chips that can run faster continuously
without active cooling... even if that doesn't seem to be a goal too many manufacturers
are directly interested in.

John Savard

On Friday, August 12, 2022 at 12:28:44 AM UTC-6, Quadibloc wrote:

> I see there's more to the story.
>
> The Honeywell 29KII was derived from the 29050, and it, or descendants
> of it, are used in a lot of aircraft electronics.
>
> There were actually versions of the 29050 that went up to 100 MHz.
>
> And the 29050 design was also used as the basis for the AMD K5 processor.
> Early versions had bugs in branch prediction and the cache, but those were
> sorted out.
>
> Of course, though, it got supplanted by the K6, which wasn't designed within
> AMD, but instead came from the NextGen Nx686.That processor, unlike the
> K5, was the one that provided Intel with serious competition.

Since the 29000 design was sold to Honeywell, AMD doesn't have it to use
as a basis for something. But since the 29050 came out in 1990, while the
K5 came out in 1996, as a response to the Pentium Pro and the Pentium II,
I see a horrible missed opportunity by AMD.

Had the K5 come out in *1991* it would have been head and shoulders
above anything Intel had. And taking one year to do the minor changes to
change the instruction set to x86 seems reasonable to me... of course,
that's probably only because of total ignorance on my part as to what that
would involve.

John Savard