On Tuesday, May 11, 2021 at 8:55:36 PM UTC-5, Stephen Fuld wrote:
> On 5/11/2021 4:54 PM, Ivan Godard wrote:

> >
> > Isn't that true of any EXEC? I don't know what other systems did about
> > that - do you?
<
> On the Univac 1100 series there is an Execute instruction. If the
> instruction executed is a jump, control is transferred to the "jump to"
> address. Furthermore, if the executed instruction is a call type,
> control is transferred as before, but the return address is set to the
> instruction after the Execute instruction.
>
> And, BTW, the effective address computed by the Execute instruction (the
> address of the instruction being Executed), was went through normal
> address calculation, including optional register contents addition, etc.
<
This seems, to me, to be the correct thought train on that subject.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Friday, June 4, 2021 at 12:13:23 PM UTC-5, Quadibloc wrote:
> On Thursday, June 3, 2021 at 7:40:58 AM UTC-6, mac wrote:
> > > Which was one of the worst aspects of Itanium.
>
> > > It killed off too many RISC architectures. There would eventually
> > > have been a consolidation, but x86_64 was not the right architecture
> > > to consolidate to...
>
> > So it *was* a success.
> Not from a _sales_ point of view, but from a _strategic_ point of view,
> yes. However, IBM was big and powerful enough that it managed to
> keep the Power PC around, and indeed, Oracle kept SPARC around.
>
> If, therefore, those designs had so much technical merit that they
> were threats to x86-64 *on that basis*, Itanium would also have been
> a strategic failure. However, the world doesn't work that way. Instead,
> ARM is the only serious threat to x86 dominance - because it found
> a niche - smartphones -
<
The niche started out to be "anything but PCs" not smartphones.
<
> big enough to finance development of the
> architecture to the extent that there are implementations across a
> range of performance levels, some worthy of the desktop and server
> space.
<
Cubic dollars beats clever architecture every time (except the first.)
>
> So ARM exists as a challenger *for the same reason* that x86 is the
> undisputed champion... it has a base of installed software.
>
> John Savard

In article <3af33fa9-ee4e-4ab5-a800-0eab3f76eea4n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> However, IBM was big and powerful enough that it managed to
> keep the Power PC around, and indeed, Oracle kept SPARC around.

Oracle didn't acquire Sun until 2009-10, by which time it was clear that
Itanium wasn't going to become dominant.

IBM and Sun both embraced Itanium in its early days, but kept their own
architectures going. The Solaris port to IA-64 was announced and
cancelled; IBM was part of Project Monterey, but that was also cancelled.

The most obvious victims of Itanium were DEC with Alpha and SGI with
MIPS.

John

On Friday, June 4, 2021 at 12:48:25 PM UTC-5, John Dallman wrote:
> In article <3af33fa9-ee4e-4ab5...@googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) wrote:
>
> > However, IBM was big and powerful enough that it managed to
> > keep the Power PC around, and indeed, Oracle kept SPARC around.
> Oracle didn't acquire Sun until 2009-10, by which time it was clear that
> Itanium wasn't going to become dominant.
>
> IBM and Sun both embraced Itanium in its early days, but kept their own
> architectures going. The Solaris port to IA-64 was announced and
> cancelled; IBM was part of Project Monterey, but that was also cancelled.
>
>
> The most obvious victims of Itanium were DEC with Alpha and SGI with
> MIPS.
<
All in all, it would have been less expensive to simply buy SGI and DEC.......
>
> John

On 5/10/2021 2:19 PM, MitchAlsup wrote:
> On Monday, May 10, 2021 at 4:12:25 PM UTC-5, gareth evans wrote:
>> Did my assembler apprenticeship 40 years ago on a PDP11/20,
>> long before any cache or pipelining.
>>
>> In, say, the ARMv8 architecture, with its pipelining and
>> branch prediction, does one have to pad out instructions
>> following a branch so that the pipeline gets flushed?
> <
> No, no modern machine is requiring NoOp padding.
>>
>> Also, if the branch is not taken, should there be a string of NOPs
>> inline so that if the branch is taken, there have not been
>> any speculative instructions already executed that would
>> affect the logic of a program?
> <
> Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
>

side note... Putting a MEMBAR instruction in a branch delay slot on the
SPARC was a no-no!

On Friday, June 4, 2021 at 12:52:55 PM UTC-6, MitchAlsup wrote:
> On Friday, June 4, 2021 at 12:48:25 PM UTC-5, John Dallman wrote:

> > The most obvious victims of Itanium were DEC with Alpha and SGI with
> > MIPS.

> All in all, it would have been less expensive to simply buy SGI and DEC.......

Oh, but that would require government approval which would be unlikely
to be forthcoming.

There is this nasty little thing called antitrust law, you know.

John Savard

On Friday, June 4, 2021 at 11:08:40 AM UTC-6, Quadibloc wrote:
> On Friday, May 14, 2021 at 3:42:21 PM UTC-6, MitchAlsup wrote:
> > On Friday, May 14, 2021 at 2:52:19 PM UTC-5, BGB wrote:

> > > A wider machine can ignore the wide-execute encoding and do its own
> > > bundling if it wants.

> > But you burned those bits ! and thus wasted entropy.

> Now _there's_ a place where my Concertina II architecture shines.

If I'm so good at squeezing an instruction set until it screams in
agony...

then how come ARM has a Thumb Mode which can be used to
write whole programs made out only of 16-bit instructions, and I
have been unable to approach this?

Well, I've made modifications to the pages

http://www.quadibloc.com/arch/ct14int.htm

and

http://www.quadibloc.com/arch/cp0101.htm

to the former by adding a block format currently listed as the eleventh,
and to the latter by placing the 16-bit instruction set at the bottom of the
page.

Now, at least, fairly extensive sequences of code consisting only of
16-bit instructions can be written and included in programs if desired;
the only overhead being a 16-bit header in each 256-bit block.

John Savard

jgd@cix.co.uk (John Dallman) writes:
>The most obvious victims of Itanium were DEC with Alpha and SGI with
>MIPS.

HP-PA.

But it seems to me that SGI and DEC/Compaq had problems independent of
IA-64. IA-64 was a welcome escape hatch to get rid of the
no-longer-wanted legacy. I have not followed HP-PA enough to make
similar guesses for that, or to make an opposite guess.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, June 4, 2021 at 3:58:07 PM UTC-6, Quadibloc wrote:

> then how come ARM has a Thumb Mode which can be used to
> write whole programs made out only of 16-bit instructions, and I
> have been unable to approach this?

My pure 16-bit instruction set is _almost_ complete, but it does
leave *one* thing out that ARM's Thumb Mode includes. You
have to switch to 32-bit instructions to do a subroutine jump.

While that would be easy enough to remedy, since such a subroutine
jump would specify a particular register as the location of the return
address, that would distort the architecture, essentially warping the
choice of calling conventions.

John Savard

On Friday, June 4, 2021 at 4:58:07 PM UTC-5, Quadibloc wrote:
> On Friday, June 4, 2021 at 11:08:40 AM UTC-6, Quadibloc wrote:
> > On Friday, May 14, 2021 at 3:42:21 PM UTC-6, MitchAlsup wrote:
> > > On Friday, May 14, 2021 at 2:52:19 PM UTC-5, BGB wrote:
>
> > > > A wider machine can ignore the wide-execute encoding and do its own
> > > > bundling if it wants.
>
> > > But you burned those bits ! and thus wasted entropy.
>
> > Now _there's_ a place where my Concertina II architecture shines.
> If I'm so good at squeezing an instruction set until it screams in
> agony...
>
> then how come ARM has a Thumb Mode which can be used to
> write whole programs made out only of 16-bit instructions, and I
> have been unable to approach this?
<
Architecture is as much about "what to leave out" as "what to leave in" !!
>
> Well, I've made modifications to the pages
>
> http://www.quadibloc.com/arch/ct14int.htm
>
> and
>
> http://www.quadibloc.com/arch/cp0101.htm
>
> to the former by adding a block format currently listed as the eleventh,
> and to the latter by placing the 16-bit instruction set at the bottom of the
> page.
>
> Now, at least, fairly extensive sequences of code consisting only of
> 16-bit instructions can be written and included in programs if desired;
> the only overhead being a 16-bit header in each 256-bit block.
>
> John Savard

On 6/4/2021 5:39 PM, Quadibloc wrote:
> On Friday, June 4, 2021 at 3:58:07 PM UTC-6, Quadibloc wrote:
>
>> then how come ARM has a Thumb Mode which can be used to
>> write whole programs made out only of 16-bit instructions, and I
>> have been unable to approach this?
>
> My pure 16-bit instruction set is _almost_ complete, but it does
> leave *one* thing out that ARM's Thumb Mode includes. You
> have to switch to 32-bit instructions to do a subroutine jump.
>

I had followed after Thumb2 here...
0zzz..Dzzz: 16-bit (more or less)
Ezzz/ Fzzz: 32-bit (or 32+ bits)

There is a certain advantage to being able to freely mix 16 and 32 bit
instructions without needing some sort of mode-change.

In ASM code, it is also possible to use 16-bit ops alongside WEX
bundles, ... However, this isn't done by the main codegen mostly because
the "WEXifier" can't deal with 16-bit encodings (this would require the
compiler to take a different approach, and effectively split the backend
into multiple pieces; adding an intermediate stage which represents ASM
instructions in the form of arrays or linked-lists or similar).

I did experiment some with some 24-bit ops, but my current leaning is
"they aren't worth it".

Also there is a property with the ISA at present that, if one starts
disassembling at a random location within the middle of a 32-bit
instruction, then typically the decoded instruction stream will realign
itself within 1 or 2 instructions (or within 0 instructions by looking
at the prior 2 instruction words). The breaks between instructions are
also fairly easy to determine in a hex dump. Similarly, E or F in the
high order bits of the 2nd word in a 32-bit op is relatively uncommon.

However, if one throws 24 bit ops into the mix, this property goes out
the window (and a misaligned instruction-stream is basically confetti).

> While that would be easy enough to remedy, since such a subroutine
> jump would specify a particular register as the location of the return
> address, that would distort the architecture, essentially warping the
> choice of calling conventions.
>

I used a Link Register (LR).

Implicitly, some contexts are using R1 as a secondary/stand-in Link
Register, and some instructions like "JMP R1" have been defined to
behave as-if R1 were the link register.

Though, in this case, this is mostly related to a recent semantics tweak:
LR(47: 0): Contains the saved PC address;
LR(63:48): Contains some captured bits from SR.

Implicitly, PC now implicitly mirrors these same bits in the same layout
as LR.

RTS and RTSU will restore these bits into SR.

Likewise, "JMP R1" will also restore these bits, wheres "JMP Rn" with
any other register will ignore the high-order bits from the register
(and keep whatever is already in these bits).

The need for a secondary link register mostly comes up in prolog and
epilog compression, and some other related forms of short-fragment code
reuse.

The reason for preserving these bits is that it resolves some issues
with the semantics.

In article <2021Jun4.235513@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> HP-PA.
>
> But it seems to me that SGI and DEC/Compaq had problems independent
> of IA-64. IA-64 was a welcome escape hatch to get rid of the
> no-longer-wanted legacy. I have not followed HP-PA enough to make
> similar guesses for that, or to make an opposite guess.

Itanium was the planned replacement for PA-RISC. When HP approached Intel
to partner on the project, their outline architecture was called "PA-RISC
v3".

HP felt they had some good ideas, but that fully developing a new
architecture good for a few decades would be too expensive to be
supported by the HP-UX and MPE businesses. They were quite correct about
the latter point. Itanium replacing PA-RISC as the HP-UX platform was one
of the things that went more or less as planned.

John

On 05/06/21 10:07, John Dallman wrote:
> In article <2021Jun4.235513@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> HP-PA.
>>
>> But it seems to me that SGI and DEC/Compaq had problems independent
>> of IA-64. IA-64 was a welcome escape hatch to get rid of the
>> no-longer-wanted legacy. I have not followed HP-PA enough to make
>> similar guesses for that, or to make an opposite guess.
>
> Itanium was the planned replacement for PA-RISC. When HP approached Intel
> to partner on the project, their outline architecture was called "PA-RISC
> v3".
>
> HP felt they had some good ideas, but that fully developing a new
> architecture good for a few decades would be too expensive to be
> supported by the HP-UX and MPE businesses. They were quite correct about
> the latter point. Itanium replacing PA-RISC as the HP-UX platform was one
> of the things that went more or less as planned.

Having the Itanic as the forward path allowed HP salesmen to
keep the PA-RISC customers (e.g. telecom) on board, and dissuade
them from defecting to alternatives.

For a while :)

On 04/06/2021 23:39, Quadibloc wrote:
> ... since such a subroutine
> jump would specify a particular register as the location of the return
> address, ...

Shades of the nightmare that is / was the 1802 microprocessor where
you changed the register that was the current program counter,
a contrivance that suggests to me that that the designer of that
ISA had very limited programming experience, maybe simple programs
with no nested subroutines!

On Friday, June 4, 2021 at 5:34:02 PM UTC-6, MitchAlsup wrote:

> Architecture is as much about "what to leave out" as "what to leave in" !!

Well, I'm leaving that as an exercise for others.

That is, as an example, you are quite correct that VLIW is lightweight, and
so my mega-CISC instruction set, when it's complete, would be a poor fit.

But the spec is meant for partial implementations - by defining the opcodes for
different kinds of machines, though, they can all have the same opcodes for the
instructions they have in common.

So leaving out is an exercise for the implementor...

John Savard

On Saturday, June 5, 2021 at 3:14:33 AM UTC-6, Tom Gardner wrote:

> Having the Itanic as the forward path allowed HP salesmen to
> keep the PA-RISC customers (e.g. telecom) on board, and dissuade
> them from defecting to alternatives.

> For a while :)

Well, one can hardly fault HP for not having a crystal ball.

And with Xeon E7 v2, Intel brought over the special RAS features
that were confined to the Itanium to their x86 line. So HP has a
reasonable alternative to migrate to which is likely to be around
for some time.

If they don't like that, and are unhappy with their relationship to
Intel, there's always ARM.

John Savard

In article <c47c2758-dd6d-4867-9aed-1b5273d9e93fn@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> And with Xeon E7 v2, Intel brought over the special RAS features
> that were confined to the Itanium to their x86 line. So HP has a
> reasonable alternative to migrate to which is likely to be around
> for some time.

It's been clear for some time that's what they're going to do, replacing
HP-UX with Linux.

> If they don't like that, and are unhappy with their relationship to
> Intel, there's always ARM.

They sacrificed their ability to get meaningfully cross with Intel about
Itanium when they sold their in-house Itanium design team to Intel.

John

On Saturday, June 5, 2021 at 4:01:28 AM UTC-6, gareth evans wrote:
> On 04/06/2021 23:39, Quadibloc wrote:
> > ... since such a subroutine
> > jump would specify a particular register as the location of the return
> > address, ...

> Shades of the nightmare that is / was the 1802 microprocessor where
> you changed the register that was the current program counter,
> a contrivance that suggests to me that that the designer of that
> ISA had very limited programming experience, maybe simple programs
> with no nested subroutines!

On the ARM, a _fixed_ register is the program counter.

On my architecture, the program counter is the program counter, and not
one of the general registers.

But there is no stack.

Subroutine calls save the return address in one of the registers according
to whatever calling convention the user may choose. I imagine that a common
choice will be to place the return address in a register that the called program
uses as a base register, so that a return can be made by a conditional jump
instruction with that register as the base, a displacement of zero, and a condition
of always.

This is how it was done on the IBM System/360.

My architecture, however, _differs_ from the IBM System/360 in the following
respect: there are families of addressing modes which use different registers
as base registers.

Integer general registers 25 through 31 are the registers that may be used
as base registers with 16-bit displacements.

Integer general register 24 may be used as a base register with a 15-bit
displacement.

Integer general registers 9 through 15 may be used as base registers with
12-bit displacements.

Integer general registers 17 through 23 may be used as base registers with
20-bit displacements.

Integer general register 16 may be used as a base register with a 9-bit
displacement; this is the one used for memory-reference instructions in
16-bit instruction only code.

The idea is that instructions have three-bit fields to indicate a base register.

The use of register 24 as a base register allows programs using 12-bit
displacements for shorter address constants within instructions to have
a main 32,767 byte data area, following the scheme IBM used on the
unique 360/20 computer.

Basically, a few general registers are used as base registers in a typical
program, leaving most of the 32 integer general registers available for
computation. (Registers 1 through 7 are available for indexing.)

But any given integer general register may be used as a base register for
a memory area of *only one size*, to avoid certain kinds of confusion.

John Savard

On 6/5/2021 6:07 AM, Quadibloc wrote:
> On Saturday, June 5, 2021 at 4:01:28 AM UTC-6, gareth evans wrote:
>> On 04/06/2021 23:39, Quadibloc wrote:
>>> ... since such a subroutine
>>> jump would specify a particular register as the location of the return
>>> address, ...
>
>> Shades of the nightmare that is / was the 1802 microprocessor where
>> you changed the register that was the current program counter,
>> a contrivance that suggests to me that that the designer of that
>> ISA had very limited programming experience, maybe simple programs
>> with no nested subroutines!
>
> On the ARM, a _fixed_ register is the program counter.
>
> On my architecture, the program counter is the program counter, and not
> one of the general registers.
>
> But there is no stack.
>
> Subroutine calls save the return address in one of the registers according
> to whatever calling convention the user may choose. I imagine that a common
> choice will be to place the return address in a register that the called program
> uses as a base register, so that a return can be made by a conditional jump
> instruction with that register as the base, a displacement of zero, and a condition
> of always.
>
> This is how it was done on the IBM System/360.
>
> My architecture, however, _differs_ from the IBM System/360 in the following
> respect: there are families of addressing modes which use different registers
> as base registers.

In general, ISTM that having different sets of registers with different
capabilities is not a good idea. You invariably want more of one type
than there are and don't use all of another type. It also complicates
the compiler.

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

gareth evans <headstone255@yahoo.com> writes:
> Shades of the nightmare that is / was the 1802 microprocessor where
> you changed the register that was the current program counter,
> a contrivance that suggests to me that that the designer of that
> ISA had very limited programming experience, maybe simple programs
> with no nested subroutines!

I remember Tom Pittman, author of Tiny BASIC, was very enthusiastic about
this feature in his 1802 implementation. You have to remember that the base
Super ELF had 256 bytes of RAM, and each K of additional memory was a
miracle. Mr. Pittman got a LOT of capability into each byte, and apparently
used the PC-switching technique to the utmost.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Friday, June 4, 2021 at 11:14:16 PM UTC-5, BGB wrote:
> On 6/4/2021 5:39 PM, Quadibloc wrote:

> > While that would be easy enough to remedy, since such a subroutine
> > jump would specify a particular register as the location of the return
> > address, that would distort the architecture, essentially warping the
> > choice of calling conventions.
> >
> I used a Link Register (LR).
>
>
> Implicitly, some contexts are using R1 as a secondary/stand-in Link
> Register, and some instructions like "JMP R1" have been defined to
> behave as-if R1 were the link register.
<
In Mc 88120, we used the jump-predict-table for JMP R~=0
and we used the call-return-stack for JMP R0
>

jgd@cix.co.uk (John Dallman) writes:
>In article <2021Jun4.235513@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> HP-PA.
>>
>> But it seems to me that SGI and DEC/Compaq had problems independent
>> of IA-64. IA-64 was a welcome escape hatch to get rid of the
>> no-longer-wanted legacy. I have not followed HP-PA enough to make
>> similar guesses for that, or to make an opposite guess.
>
>Itanium was the planned replacement for PA-RISC.

So it was the planned escape hatch to get rid of the no-longer-wanted
legacy? :-)

>When HP approached Intel
>to partner on the project, their outline architecture was called "PA-RISC
>v3".

And for Intel it also became the planned escape hatch to get rid of
the no-longer wanted legacy.

>HP felt they had some good ideas, but that fully developing a new
>architecture good for a few decades would be too expensive to be
>supported by the HP-UX and MPE businesses. They were quite correct about
>the latter point. Itanium replacing PA-RISC as the HP-UX platform was one
>of the things that went more or less as planned.

So I guess they also saw the writing on the wall that they would not
be able to afford the ever-increasing costs of designing
implementations of their private architecture. And indtead they fell
into the trap of designing an even more cost-intensive architecture.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Quadibloc <jsavard@ecn.ab.ca>:
>On the ARM, a _fixed_ register is the program counter.

That's what the PDP-11 did. I don't know if it was the first architecture to put the PC
in a register but it was certainly the most famous.

It made relative addressing the same as indexed addressing, using the PC as the index register.
It had a (R)+ and @(R)+ modes, use the register as the address and then inrement it by the address and
then in the second case, use that as the indirect address.
Hence (PC)+ was an immediate operand and @(PC)+ was absolute addressing.

Considering how expensive transistors were in 1969, it was a cute hack to simplify the architecture
and remove what otherwise would have been special cases.

The IBM 360 made you use a general register to address your code. In
retrospect that was a mistake which they fixed by adding relative
branches much later.

--
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 Saturday, June 5, 2021 at 10:19:31 AM UTC-5, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On the ARM, a _fixed_ register is the program counter.
> That's what the PDP-11 did. I don't know if it was the first architecture to put the PC
> in a register but it was certainly the most famous.
>
> It made relative addressing the same as indexed addressing, using the PC as the index register.
> It had a (R)+ and @(R)+ modes, use the register as the address and then inrement it by the address and
> then in the second case, use that as the indirect address.
> Hence (PC)+ was an immediate operand and @(PC)+ was absolute addressing.
<
It was a cute trick, but made pipelineing difficult.
>
> Considering how expensive transistors were in 1969, it was a cute hack to simplify the architecture
> and remove what otherwise would have been special cases.
>
> The IBM 360 made you use a general register to address your code. In
> retrospect that was a mistake which they fixed by adding relative
> branches much later.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to MitchAlsup <MitchAlsup@aol.com>:
>On Saturday, June 5, 2021 at 10:19:31 AM UTC-5, John Levine wrote:
>> According to Quadibloc <jsa...@ecn.ab.ca>:
>> >On the ARM, a _fixed_ register is the program counter.
>> That's what the PDP-11 did. I don't know if it was the first architecture to put the PC
>> in a register but it was certainly the most famous.
>>
>> It made relative addressing the same as indexed addressing, using the PC as the index register.
>> It had a (R)+ and @(R)+ modes, use the register as the address and then inrement it by the address and
>> then in the second case, use that as the indirect address.
>> Hence (PC)+ was an immediate operand and @(PC)+ was absolute addressing.
><
>It was a cute trick, but made pipelineing difficult.

Was there ever a PDP-11 that was pipelined? This was quite a while ago.

Also, the address modes were all fixed places in the first word of the
instruction so I would think it'd be simple enough to recognize those
two and take the words out of the instruction stream. It has to do
roughly the same thing for the index words in indexed address modes.

--
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