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?

Also, if the branch is not taken, should there be a string of NOPs
inlineso that if the branch is taken, there have not been
any speculative instructions already executed that would
affect the logic of a program?

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.

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.

Not Alpha - the ISA guarantees no branch or load delay slots.

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.

AMD 29000 had branch delay slots.

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

MitchAlsup <MitchAlsup@aol.com> writes:
>Only MIPS, SPARC, 88K, and Alpha had branch delay slots.

Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
from TI, and Trimedia from Philips) elevated branch delay slot to an
art form: the had several branch delay slots, and several nops, some
of which where for filling multiple delay slots.

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> MitchAlsup <MitchAlsup@aol.com> writes:
>>Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
>
> Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
> from TI, and Trimedia from Philips) elevated branch delay slot to an
> art form: the had several branch delay slots, and several nops, some
> of which where for filling multiple delay slots.

IIRC, the 801 had branch instructions with and without delay slots,
so the compiler could chose.

On Tuesday, May 11, 2021 at 4:45:32 AM UTC-6, Thomas Koenig wrote:

> IIRC, the 801 had branch instructions with and without delay slots,
> so the compiler could chose.

So if useful instructions can be placed in them, the one with delay
slots is used; otherwise, no need to waste memory on no-operation
instructions.

John Savard

On 5/11/2021 2:09 AM, Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
>
> Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
> from TI, and Trimedia from Philips) elevated branch delay slot to an
> art form: the had several branch delay slots, and several nops, some
> of which where for filling multiple delay slots.
>
> - anton
>

Well put, Anton.

I was on the Trimedia architecture team. There were three branch delay
slots, and you could put branches in the delay slots, which gave you
what amounted to an EXEC instruction. Asm for it was indeed an art form.

On Tuesday, May 11, 2021 at 3:31:10 PM UTC-5, Ivan Godard wrote:
> On 5/11/2021 2:09 AM, Anton Ertl wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> >> Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
> >
> > Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
> > from TI, and Trimedia from Philips) elevated branch delay slot to an
> > art form: the had several branch delay slots, and several nops, some
> > of which where for filling multiple delay slots.
> >
> > - anton
> >
> Well put, Anton.
>
> I was on the Trimedia architecture team. There were three branch delay
> slots, and you could put branches in the delay slots, which gave you
> what amounted to an EXEC instruction. Asm for it was indeed an art form.
<
It gave you a semi-literate EXC instruction, but if the EXCed instruction was
a branch, you just lost control of where you were.

On 5/11/2021 2:50 PM, MitchAlsup wrote:
> On Tuesday, May 11, 2021 at 3:31:10 PM UTC-5, Ivan Godard wrote:
>> On 5/11/2021 2:09 AM, Anton Ertl wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>> Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
>>>
>>> Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
>>> from TI, and Trimedia from Philips) elevated branch delay slot to an
>>> art form: the had several branch delay slots, and several nops, some
>>> of which where for filling multiple delay slots.
>>>
>>> - anton
>>>
>> Well put, Anton.
>>
>> I was on the Trimedia architecture team. There were three branch delay
>> slots, and you could put branches in the delay slots, which gave you
>> what amounted to an EXEC instruction. Asm for it was indeed an art form.
> <
> It gave you a semi-literate EXC instruction, but if the EXCed instruction was
> a branch, you just lost control of where you were.
>

Isn't that true of any EXEC? I don't know what other systems did about
that - do you?

On 5/11/2021 4:54 PM, Ivan Godard wrote:
> On 5/11/2021 2:50 PM, MitchAlsup wrote:
>> On Tuesday, May 11, 2021 at 3:31:10 PM UTC-5, Ivan Godard wrote:
>>> On 5/11/2021 2:09 AM, Anton Ertl wrote:
>>>> MitchAlsup <Mitch...@aol.com> writes:
>>>>> Only MIPS, SPARC, 88K, and Alpha had branch delay slots.
>>>>
>>>> Alpha hadn't. 29K did AFAIK had. Various signal processors (IIRC
>>>> from TI, and Trimedia from Philips) elevated branch delay slot to an
>>>> art form: the had several branch delay slots, and several nops, some
>>>> of which where for filling multiple delay slots.
>>>>
>>>> - anton
>>>>
>>> Well put, Anton.
>>>
>>> I was on the Trimedia architecture team. There were three branch delay
>>> slots, and you could put branches in the delay slots, which gave you
>>> what amounted to an EXEC instruction. Asm for it was indeed an art form.
>> <
>> It gave you a semi-literate EXC instruction, but if the EXCed
>> instruction was
>> a branch, you just lost control of where you were.
>>
>
> 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.

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

On 5/10/2021 4: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.
>

Adding to this list:
SuperH, TMS320, ...

I skipped out on them because:
They suck;
They would have exposed awkward implementation details (*);
Much of the time, they would just end up with NOPs anyways;
...

*: Say, one has an ISA where the bundling, handling of larger
instruction encodings, ...

May be handled as one of:
Read and decoded, and executed, all at once;
Read, decoded, and executed one instruction word at a time;
...

When I designed my ISA, I had a few design goals:
A single-wide core should still be able to execute wide-execute code;
A wider core should be able to execute code meant for a narrower core;
A core should be able to ignore the bundle encoding and use superscalar
if it wants;
....

Delay slots would have caused this to fall on its face.

For example, there is a single-wide profile for BJX2, which (provided
the same instructions are supported) can execute code intended to use WEX.

However, jumbo encodings use a different mechanism:
Jumbo prefixes are executed one at a time, initially behaving like NOPs;
On the final instruction, the larger immediate just sorta appears out of
nowhere.

Similarly, the emulator also checks and "lints" bundles for being
well-formed, and will decode instructions as "BREAK" if they violate
bundling rules (and thus lead to a behavioral divergence). This is
intended mostly to try to sanity-check the compiler output, but
sometimes detects ASM bugs as well (I recently tightened up a few of the
rules after I had noticed some evidence of behavioral divergence in the
Verilog implementation).

There are some features I had looked at which if-supported can also make
for possible issues:
Supporting a second (Load Only) memory-port in Lane 2;
Allowing scalar FPU ops to be executed in Lane 2 (*2);
...

Mostly in that, if used, these operations would break on a core which
does not support them (this code could only be safely executed in scalar
mode).

*2: I have experimentally allowed this. It does allow for a speedup in
floating-point intensive code, generally by allowing memory access or
similar to happen in parallel with FPU operations or "narrow" SIMD
operations (2xFP32 or 4xFP16). Still not formally allowed though.

Likewise, 3-wide code would have broken on a 2-wide core, and it would
have been possible to compose code on 2-wide which would have broken on
a 3-wide core. However, the differences in cost and capabilities favored
eliminating the 2-wide case entirely (the 3-wide was only slightly more
expensive; and was more capable in terms of what it could do with 2-wide
code).

Wider doesn't look likely at the moment, and it is likely if a 4+ core
were done, it would probably be based on OoO superscalar rather than VLIW.

I suspect for the most part, 3-wide is already mostly at the limits of
what level of usable ILP tends to exist for an in-order design, and that
going much wider would be essentially pointless.

....

Nevermind if DRAM bandwidth is still an issue:
Despite the much faster bus (and faster L2 speeds), the bandwidth to
external DRAM is still apparently only ~ 1/4 what is claimed for 72-pin
SIMM RAM on a 486 (seeing stuff claiming a 486 could memcpy 50MB/s in
external DRAM).

BGB <cr88192@gmail.com> schrieb:
> On 5/10/2021 4: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.
>>
>
> Adding to this list:
> SuperH, TMS320, ...

Don't forget HP-PA.

>
>
> I skipped out on them because:
> They suck;

I worked on HP-PA machines for a while, it was not too bad in
instructions per cycle.

On Friday, May 14, 2021 at 12:24:04 PM UTC-5, BGB wrote:
> On 5/10/2021 4: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.
> >
> Adding to this list:
> SuperH, TMS320, ...
>
>
> I skipped out on them because:
> They suck;
> They would have exposed awkward implementation details (*);
> Much of the time, they would just end up with NOPs anyways;
> ...
>
>
> *: Say, one has an ISA where the bundling, handling of larger
> instruction encodings, ...
<
Say one decided that this wastes more entropy that one wants to allow:
>
> May be handled as one of:
> Read and decoded, and executed, all at once;
> Read, decoded, and executed one instruction word at a time;
> ...
<
The Std RISC-like ISA allows for wide implementations where the compiler
can be rather ignorant of how wide the machine happens to be.
>
> When I designed my ISA, I had a few design goals:
> A single-wide core should still be able to execute wide-execute code;
> A wider core should be able to execute code meant for a narrower core;
> A core should be able to ignore the bundle encoding and use superscalar
> if it wants;
<
Is it NOT simpler simply not to have wide execute encoding, this lets narrow
machines execute as they see fit, and for machines that are significantly
wide, decide for themselves how to bundle instructions ?
> ...
>
> Delay slots would have caused this to fall on its face.
<
Absofriggenlutely ! Delay slots are a bad idea that in the heat of battle 1st
generation RISC could not afford to lose the perf they apparently bought,
but that created a large burden on all future implementatnions.
>
>
> For example, there is a single-wide profile for BJX2, which (provided
> the same instructions are supported) can execute code intended to use WEX.
>
> However, jumbo encodings use a different mechanism:
> Jumbo prefixes are executed one at a time, initially behaving like NOPs;
> On the final instruction, the larger immediate just sorta appears out of
> nowhere.
>
> Similarly, the emulator also checks and "lints" bundles for being
> well-formed, and will decode instructions as "BREAK" if they violate
> bundling rules (and thus lead to a behavioral divergence). This is
> intended mostly to try to sanity-check the compiler output, but
> sometimes detects ASM bugs as well (I recently tightened up a few of the
> rules after I had noticed some evidence of behavioral divergence in the
> Verilog implementation).
>
>
>
> There are some features I had looked at which if-supported can also make
> for possible issues:
> Supporting a second (Load Only) memory-port in Lane 2;
> Allowing scalar FPU ops to be executed in Lane 2 (*2);
> ...
>
> Mostly in that, if used, these operations would break on a core which
> does not support them (this code could only be safely executed in scalar
> mode).
>
> *2: I have experimentally allowed this. It does allow for a speedup in
> floating-point intensive code, generally by allowing memory access or
> similar to happen in parallel with FPU operations or "narrow" SIMD
> operations (2xFP32 or 4xFP16). Still not formally allowed though.
>
>
> Likewise, 3-wide code would have broken on a 2-wide core, and it would
> have been possible to compose code on 2-wide which would have broken on
> a 3-wide core. However, the differences in cost and capabilities favored
> eliminating the 2-wide case entirely (the 3-wide was only slightly more
> expensive; and was more capable in terms of what it could do with 2-wide
> code).
>
> Wider doesn't look likely at the moment, and it is likely if a 4+ core
> were done, it would probably be based on OoO superscalar rather than VLIW.
>
> I suspect for the most part, 3-wide is already mostly at the limits of
> what level of usable ILP tends to exist for an in-order design, and that
> going much wider would be essentially pointless.
>
> ...
>
>
> Nevermind if DRAM bandwidth is still an issue:
> Despite the much faster bus (and faster L2 speeds), the bandwidth to
> external DRAM is still apparently only ~ 1/4 what is claimed for 72-pin
> SIMM RAM on a 486 (seeing stuff claiming a 486 could memcpy 50MB/s in
> external DRAM).

On Friday, May 14, 2021 at 12:32:02 PM UTC-5, Thomas Koenig wrote:
> BGB <cr8...@gmail.com> schrieb:
> > On 5/10/2021 4: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.
> >>
> >
> > Adding to this list:
> > SuperH, TMS320, ...
> Don't forget HP-PA.
> >
> >
> > I skipped out on them because:
> > They suck;
> I worked on HP-PA machines for a while, it was not too bad in
> instructions per cycle.
<
HP-PA was not nearly as bad as the machine that HP jumped onto
after HP-PA !!

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Friday, May 14, 2021 at 12:32:02 PM UTC-5, Thomas Koenig wrote:
>> BGB <cr8...@gmail.com> schrieb:
>> > On 5/10/2021 4: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.
>> >>
>> >
>> > Adding to this list:
>> > SuperH, TMS320, ...
>> Don't forget HP-PA.
>> >
>> >
>> > I skipped out on them because:
>> > They suck;
>> I worked on HP-PA machines for a while, it was not too bad in
>> instructions per cycle.
><
> HP-PA was not nearly as bad as the machine that HP jumped onto
> after HP-PA !!

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

On 5/14/2021 1:11 PM, MitchAlsup wrote:
> On Friday, May 14, 2021 at 12:24:04 PM UTC-5, BGB wrote:
>> On 5/10/2021 4: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.
>>>
>> Adding to this list:
>> SuperH, TMS320, ...
>>
>>
>> I skipped out on them because:
>> They suck;
>> They would have exposed awkward implementation details (*);
>> Much of the time, they would just end up with NOPs anyways;
>> ...
>>
>>
>> *: Say, one has an ISA where the bundling, handling of larger
>> instruction encodings, ...
> <
> Say one decided that this wastes more entropy that one wants to allow:
>>
>> May be handled as one of:
>> Read and decoded, and executed, all at once;
>> Read, decoded, and executed one instruction word at a time;
>> ...
> <
> The Std RISC-like ISA allows for wide implementations where the compiler
> can be rather ignorant of how wide the machine happens to be.

Possibly, though most of the "hard" parts of the work for the compiler
still apply to optimizing code for an in-order superscalar.

Namely, the compiler needs to figure out which instructions it can
shuffle around, and try to get them in an order that minimizes
interlocks and dependencies between instructions.

After this, scanning along and putting instructions into bundles is more
an "icing on the cake" thing. Compiler mostly has to verify that the
instructions can be safely executed in parallel according to the ISA
rules, and then flag those that can.

>>
>> When I designed my ISA, I had a few design goals:
>> A single-wide core should still be able to execute wide-execute code;
>> A wider core should be able to execute code meant for a narrower core;
>> A core should be able to ignore the bundle encoding and use superscalar
>> if it wants;
> <
> Is it NOT simpler simply not to have wide execute encoding, this lets narrow
> machines execute as they see fit, and for machines that are significantly
> wide, decide for themselves how to bundle instructions ?

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

It costs ~ 1 bit of encoding space, but doesn't add any additional
complexity for an implementation that just wants to ignore it.

The wide execute encoding is more intended for processors that are
effectively too limited to be able to figure this out themselves (yet
still capable enough to be able to afford it at all).

Besides the 3-wide profile, the other profile is currently 1 wide.

This is mostly because the 3-wide profile has little hope of fitting
into an XC7S25 or similar.

However, on the XC7S50 and XC7A100, I can to do this, but not that much
more than this.

I have not yet tried putting it in an ECP5 or similar (but, dev boards
with Lattice FPGAs seem to be a lot harder to find on Amazon than ones
with Xilinx or Altera FPGAs).

>> ...
>>
>> Delay slots would have caused this to fall on its face.
> <
> Absofriggenlutely ! Delay slots are a bad idea that in the heat of battle 1st
> generation RISC could not afford to lose the perf they apparently bought,
> but that created a large burden on all future implementatnions.

Yeah.

>>
>>
>> For example, there is a single-wide profile for BJX2, which (provided
>> the same instructions are supported) can execute code intended to use WEX.
>>
>> However, jumbo encodings use a different mechanism:
>> Jumbo prefixes are executed one at a time, initially behaving like NOPs;
>> On the final instruction, the larger immediate just sorta appears out of
>> nowhere.
>>
>> Similarly, the emulator also checks and "lints" bundles for being
>> well-formed, and will decode instructions as "BREAK" if they violate
>> bundling rules (and thus lead to a behavioral divergence). This is
>> intended mostly to try to sanity-check the compiler output, but
>> sometimes detects ASM bugs as well (I recently tightened up a few of the
>> rules after I had noticed some evidence of behavioral divergence in the
>> Verilog implementation).
>>
>>
>>
>> There are some features I had looked at which if-supported can also make
>> for possible issues:
>> Supporting a second (Load Only) memory-port in Lane 2;
>> Allowing scalar FPU ops to be executed in Lane 2 (*2);
>> ...
>>
>> Mostly in that, if used, these operations would break on a core which
>> does not support them (this code could only be safely executed in scalar
>> mode).
>>
>> *2: I have experimentally allowed this. It does allow for a speedup in
>> floating-point intensive code, generally by allowing memory access or
>> similar to happen in parallel with FPU operations or "narrow" SIMD
>> operations (2xFP32 or 4xFP16). Still not formally allowed though.
>>
>>
>> Likewise, 3-wide code would have broken on a 2-wide core, and it would
>> have been possible to compose code on 2-wide which would have broken on
>> a 3-wide core. However, the differences in cost and capabilities favored
>> eliminating the 2-wide case entirely (the 3-wide was only slightly more
>> expensive; and was more capable in terms of what it could do with 2-wide
>> code).
>>
>> Wider doesn't look likely at the moment, and it is likely if a 4+ core
>> were done, it would probably be based on OoO superscalar rather than VLIW.
>>
>> I suspect for the most part, 3-wide is already mostly at the limits of
>> what level of usable ILP tends to exist for an in-order design, and that
>> going much wider would be essentially pointless.
>>
>> ...
>>
>>
>> Nevermind if DRAM bandwidth is still an issue:
>> Despite the much faster bus (and faster L2 speeds), the bandwidth to
>> external DRAM is still apparently only ~ 1/4 what is claimed for 72-pin
>> SIMM RAM on a 486 (seeing stuff claiming a 486 could memcpy 50MB/s in
>> external DRAM).

On Friday, May 14, 2021 at 2:52:19 PM UTC-5, BGB wrote:
> On 5/14/2021 1:11 PM, MitchAlsup wrote:
> > On Friday, May 14, 2021 at 12:24:04 PM UTC-5, BGB wrote:
> >> On 5/10/2021 4: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.
> >>>
> >> Adding to this list:
> >> SuperH, TMS320, ...
> >>
> >>
> >> I skipped out on them because:
> >> They suck;
> >> They would have exposed awkward implementation details (*);
> >> Much of the time, they would just end up with NOPs anyways;
> >> ...
> >>
> >>
> >> *: Say, one has an ISA where the bundling, handling of larger
> >> instruction encodings, ...
> > <
> > Say one decided that this wastes more entropy that one wants to allow:
> >>
> >> May be handled as one of:
> >> Read and decoded, and executed, all at once;
> >> Read, decoded, and executed one instruction word at a time;
> >> ...
> > <
> > The Std RISC-like ISA allows for wide implementations where the compiler
> > can be rather ignorant of how wide the machine happens to be.
<
> Possibly, though most of the "hard" parts of the work for the compiler
> still apply to optimizing code for an in-order superscalar.
<
We actually found this not to be true in the case of the Mc 88120.
Pretty much anything compiled for Mc 88100 ran really well on the
'120--in fact we did not have access to a '120 compiler and used
the '100 simulator to pipe instructions to the '120 simulator.
<
Now could a bit more have been obtained--sure--but we were getting
5.99 ipc out of MATRIX300, and 2.05 ipc out of XLISP ! This seemed
to be "enough" for a 1991 design 1994 chip.
>
> Namely, the compiler needs to figure out which instructions it can
> shuffle around, and try to get them in an order that minimizes
> interlocks and dependencies between instructions.
<
We had the HW to do this--with a bit of annotation in the register
specification fields and the reservation station design. In a packet,
register specifiers ended up 6-bits wide, if the HoB was 0 the field
specified a register which was read from the file, forwarding,...
If the HoB was 1, we knew that the operand was delivered from
within the packet, and the field encoded the "slot" in the machine
that would deliver said result. We did similar tricks on the destination
register to say the result was delivered and became dead within the
packed.
<
The packet builder built packets AFTER the instructions retired from
the machine, so we have architectural (observed) order. unconditional
branches simply did not exist in the packet. Instruction under a shadow
of a branch were so annotated along with their position {Then-clause or
Else-clause}.
>
> After this, scanning along and putting instructions into bundles is more
> an "icing on the cake" thing. Compiler mostly has to verify that the
> instructions can be safely executed in parallel according to the ISA
> rules, and then flag those that can.
> >>
> >> When I designed my ISA, I had a few design goals:
> >> A single-wide core should still be able to execute wide-execute code;
> >> A wider core should be able to execute code meant for a narrower core;
> >> A core should be able to ignore the bundle encoding and use superscalar
> >> if it wants;
> > <
> > Is it NOT simpler simply not to have wide execute encoding, this lets narrow
> > machines execute as they see fit, and for machines that are significantly
> > wide, decide for themselves how to bundle instructions ?
<
> 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.
>
> It costs ~ 1 bit of encoding space, but doesn't add any additional
> complexity for an implementation that just wants to ignore it.
>
>
> The wide execute encoding is more intended for processors that are
> effectively too limited to be able to figure this out themselves (yet
> still capable enough to be able to afford it at all).
>
> Besides the 3-wide profile, the other profile is currently 1 wide.
>
> This is mostly because the 3-wide profile has little hope of fitting
> into an XC7S25 or similar.
>
> However, on the XC7S50 and XC7A100, I can to do this, but not that much
> more than this.
<
I have been following this for a couple of years, and the 3-wide nature
appears to be due to the low clock frequency an a desire to run DOOM
and QUAKE at acceptable frame rates.
>
>
> I have not yet tried putting it in an ECP5 or similar (but, dev boards
> with Lattice FPGAs seem to be a lot harder to find on Amazon than ones
> with Xilinx or Altera FPGAs).
> >> ...
> >>
> >> Delay slots would have caused this to fall on its face.
> > <
> > Absofriggenlutely ! Delay slots are a bad idea that in the heat of battle 1st
> > generation RISC could not afford to lose the perf they apparently bought,
> > but that created a large burden on all future implementatnions.
<
> Yeah.
> >>
> >>
> >> For example, there is a single-wide profile for BJX2, which (provided
> >> the same instructions are supported) can execute code intended to use WEX.
> >>
> >> However, jumbo encodings use a different mechanism:
> >> Jumbo prefixes are executed one at a time, initially behaving like NOPs;
> >> On the final instruction, the larger immediate just sorta appears out of
> >> nowhere.
> >>
> >> Similarly, the emulator also checks and "lints" bundles for being
> >> well-formed, and will decode instructions as "BREAK" if they violate
> >> bundling rules (and thus lead to a behavioral divergence). This is
> >> intended mostly to try to sanity-check the compiler output, but
> >> sometimes detects ASM bugs as well (I recently tightened up a few of the
> >> rules after I had noticed some evidence of behavioral divergence in the
> >> Verilog implementation).
> >>
> >>
> >>
> >> There are some features I had looked at which if-supported can also make
> >> for possible issues:
> >> Supporting a second (Load Only) memory-port in Lane 2;
> >> Allowing scalar FPU ops to be executed in Lane 2 (*2);
> >> ...
> >>
> >> Mostly in that, if used, these operations would break on a core which
> >> does not support them (this code could only be safely executed in scalar
> >> mode).
> >>
> >> *2: I have experimentally allowed this. It does allow for a speedup in
> >> floating-point intensive code, generally by allowing memory access or
> >> similar to happen in parallel with FPU operations or "narrow" SIMD
> >> operations (2xFP32 or 4xFP16). Still not formally allowed though.
> >>
> >>
> >> Likewise, 3-wide code would have broken on a 2-wide core, and it would
> >> have been possible to compose code on 2-wide which would have broken on
> >> a 3-wide core. However, the differences in cost and capabilities favored
> >> eliminating the 2-wide case entirely (the 3-wide was only slightly more
> >> expensive; and was more capable in terms of what it could do with 2-wide
> >> code).
> >>
> >> Wider doesn't look likely at the moment, and it is likely if a 4+ core
> >> were done, it would probably be based on OoO superscalar rather than VLIW.
> >>
> >> I suspect for the most part, 3-wide is already mostly at the limits of
> >> what level of usable ILP tends to exist for an in-order design, and that
> >> going much wider would be essentially pointless.
> >>
> >> ...
> >>
> >>
> >> Nevermind if DRAM bandwidth is still an issue:
> >> Despite the much faster bus (and faster L2 speeds), the bandwidth to
> >> external DRAM is still apparently only ~ 1/4 what is claimed for 72-pin
> >> SIMM RAM on a 486 (seeing stuff claiming a 486 could memcpy 50MB/s in
> >> external DRAM).

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

On Tuesday, May 11, 2021 at 7:55:36 PM UTC-6, Stephen Fuld wrote:

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

That is the way to do it. That behaves as if the Execute instruction _is_
the instruction at the effective address. A branch, therefore, quite properly
loses control - but a subroutine call does not, the return is still to the code
sequence where the Execute instruction was.

So my question would be, were there instructions that got it wrong, so that
one couldn't use the Execute instruction on a Jump to Subroutine instruction
without getting a useless and dangerous result?

John Savard

On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:

> 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 true, but there was little choice then. Now we have a second chance,
ARM.

John Savard

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.

It wastes entropy _elsewhere_. Lots of it, no doubt. Having full base-index
addressing like a CISC, and banks of 32 registers like a RISC, which shouldn't
even be _possible_, it has to resort to "every trick in the book" to make the
instructions fit at all.

So there's no room for putting one bit at the front of each instruction as a
'break' bit!

Yet, I offer a _fancy_ scheme of wide-execute encoding, which adds not just
one, but *three*, bits to every instruction! How do I do this? Well, I take a tiny
sliver of the opcode space, and use it for a program block header - only if I use
a block header do I have the bits available to do the wide-execute encoding.

John Savard

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

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

On Friday, June 4, 2021 at 12:08:40 PM UTC-5, 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.
>
> It wastes entropy _elsewhere_. Lots of it, no doubt. Having full base-index
> addressing like a CISC, and banks of 32 registers like a RISC, which shouldn't
> even be _possible_,
<
My 66000 fit this one in::
a) Mem Rd,[Rbase+IMM16] is one 32-bit instruction
b) Mem Rd,[Rbase+Rindex<<scale] is one 32-bit instruction
c) Mem Rd,[Rbase+Rindex<<scale+imm32] is a 64-bit instruction.
<
> it has to resort to "every trick in the book" to make the
> instructions fit at all.
>
> So there's no room for putting one bit at the front of each instruction as a
> 'break' bit!
<
This is where PRED and CARRY and VEC-LOOP come in.........
>
> Yet, I offer a _fancy_ scheme of wide-execute encoding, which adds not just
> one, but *three*, bits to every instruction! How do I do this? Well, I take a tiny
> sliver of the opcode space, and use it for a program block header - only if I use
> a block header do I have the bits available to do the wide-execute encoding.
>
> John Savard

On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
>
> > 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 true, but there was little choice then. Now we have a second chance,
> ARM.
<
Not much of a choice:
a) mud pie
b) mud pudding
>
> John Savard