Hi!

I wanted to get a better feeling for the machine code density on
different contemporary (modern) ISA:s, including my own ISA MRISC32 of
course. I posted an article with my thoughts and the results:

https://www.bitsnbites.eu/cisc-vs-risc-code-density/

The short is that with GCC and optimizations turned on, the code for
RISC machines is roughly equally dense or denser compared to "modern"
CISC machines (x86_64 and z/Arch). Also, x86_64 appears to have an
average instruction size of ~4 bytes (i.e. same as a fixed size RISC ISA).

/Marcus

Marcus <m.delete@this.bitsnbites.eu> writes:
>https://www.bitsnbites.eu/cisc-vs-risc-code-density/

The -Os results may not be representative of real-world programs, but
may be more informative wrt. instruction set density. If on
architecture A -O2 and -O3 unroll more than on architecture B, this
will look with your method like architecture A has less code density.
-Os should minimize these kinds of effects.

Concerning "dynamic code density", if the purpose of code density is
to minimize I-cache misses, the way to go would be to measure I-cache
misses (maybe with a cache simulator to get comparable cache sizes and
get rid of prefetching artifacts; and with different I-cache sizes to
see how consistent the difference is). Instruction fetch bandwidth is
another interesting issue, with a few problems: Do you account
instruction fetches from mispredictions, or extra bytes fetched behind
a taken branch?

I wonder if there is really substance to the myth of greater code
density from CISCs, even in the past.

- 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:
> Marcus <m.delete@this.bitsnbites.eu> writes:
>>https://www.bitsnbites.eu/cisc-vs-risc-code-density/
>
> The -Os results may not be representative of real-world programs, but
> may be more informative wrt. instruction set density. If on
> architecture A -O2 and -O3 unroll more than on architecture B, this
> will look with your method like architecture A has less code density.
> -Os should minimize these kinds of effects.

So, it is obviously not only a question of the ISA, but also of
the compiler. If the cost function of the compiler in question
is good (which is questionable), then it should make choices in
the right ballpark.

But unless major distributions are compiled with -Os, the results
are not going to matter for most users (and I've seen cases
where -Os produced larger code than -O3 :-)

So, unless this is an embedded system, I think Marcus' benchmark
is probably one of the best options.

[...]

> I wonder if there is really substance to the myth of greater code
> density from CISCs, even in the past.

Good question.

On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> Marcus <m.de...@this.bitsnbites.eu> writes:
> >https://www.bitsnbites.eu/cisc-vs-risc-code-density/
>
> The -Os results may not be representative of real-world programs, but
> may be more informative wrt. instruction set density. If on
> architecture A -O2 and -O3 unroll more than on architecture B, this
> will look with your method like architecture A has less code density.
> -Os should minimize these kinds of effects.
>
> Concerning "dynamic code density", if the purpose of code density is
> to minimize I-cache misses, the way to go would be to measure I-cache
> misses (maybe with a cache simulator to get comparable cache sizes and
> get rid of prefetching artifacts; and with different I-cache sizes to
> see how consistent the difference is). Instruction fetch bandwidth is
> another interesting issue, with a few problems: Do you account
> instruction fetches from mispredictions, or extra bytes fetched behind
> a taken branch?
<
a) the purpose of greater code density is also to execute fewer instructions.
<
In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
50% more instructions at 6× the frequency for a 4× performance advantage.
I, personally, want to chip away at that 50% adder, and adding constants
to a rather std RISC instruction set has given a 25% advantage. My 66000
only executes 75%-79% as many instructions as RISC-V.
>
> I wonder if there is really substance to the myth of greater code
> density from CISCs, even in the past.
<
Given that RISC-V compressed has similar code density as several of the
CISC chips, it is competing against, apparently there is no longer "such a
great distance" between CISC code density and RISC code density.
<
AND at this point one needs to refocus on how much work is encoded
in <how few of> the application instructions.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 12/4/2022 1:46 PM, MitchAlsup wrote:
> On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
>> Marcus <m.de...@this.bitsnbites.eu> writes:
>>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
>>
>> The -Os results may not be representative of real-world programs, but
>> may be more informative wrt. instruction set density. If on
>> architecture A -O2 and -O3 unroll more than on architecture B, this
>> will look with your method like architecture A has less code density.
>> -Os should minimize these kinds of effects.
>>
>> Concerning "dynamic code density", if the purpose of code density is
>> to minimize I-cache misses, the way to go would be to measure I-cache
>> misses (maybe with a cache simulator to get comparable cache sizes and
>> get rid of prefetching artifacts; and with different I-cache sizes to
>> see how consistent the difference is). Instruction fetch bandwidth is
>> another interesting issue, with a few problems: Do you account
>> instruction fetches from mispredictions, or extra bytes fetched behind
>> a taken branch?
> <
> a) the purpose of greater code density is also to execute fewer instructions.
> <
> In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> 50% more instructions at 6× the frequency for a 4× performance advantage.
> I, personally, want to chip away at that 50% adder, and adding constants
> to a rather std RISC instruction set has given a 25% advantage. My 66000
> only executes 75%-79% as many instructions as RISC-V.

Similar probably for things like Jumbo encodings in my case, which can
somewhat cut down on the need for constant loads.

>>
>> I wonder if there is really substance to the myth of greater code
>> density from CISCs, even in the past.
> <
> Given that RISC-V compressed has similar code density as several of the
> CISC chips, it is competing against, apparently there is no longer "such a
> great distance" between CISC code density and RISC code density.
> <
> AND at this point one needs to refocus on how much work is encoded
> in <how few of> the application instructions.

Also why I am currently more in support of "limited variable length"
encodings, say:
16/32/64/96, or 16/32/48/64/96
Rather than fully variable length byte-oriented encodings.

The limited case provides nearly the same code density, but can be a lot
easier and more efficient to decode.

Granted, the most optimal encoding scheme within this space is more
subject to debate.

Does not entirely avoid the "how much stuff can I fit into a 32 bit
encoding?" issue, if the 32-bit encoding space is still the central hub
that all of the other encodings revolve around.

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

On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> >> Marcus <m.de...@this.bitsnbites.eu> writes:
> >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> >>
> >> The -Os results may not be representative of real-world programs, but
> >> may be more informative wrt. instruction set density. If on
> >> architecture A -O2 and -O3 unroll more than on architecture B, this
> >> will look with your method like architecture A has less code density.
> >> -Os should minimize these kinds of effects.
> >>
> >> Concerning "dynamic code density", if the purpose of code density is
> >> to minimize I-cache misses, the way to go would be to measure I-cache
> >> misses (maybe with a cache simulator to get comparable cache sizes and
> >> get rid of prefetching artifacts; and with different I-cache sizes to
> >> see how consistent the difference is). Instruction fetch bandwidth is
> >> another interesting issue, with a few problems: Do you account
> >> instruction fetches from mispredictions, or extra bytes fetched behind
> >> a taken branch?
> > <
> > a) the purpose of greater code density is also to execute fewer instructions.
> > <
> > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > I, personally, want to chip away at that 50% adder, and adding constants
> > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > only executes 75%-79% as many instructions as RISC-V.
> Similar probably for things like Jumbo encodings in my case, which can
> somewhat cut down on the need for constant loads.
> >>
> >> I wonder if there is really substance to the myth of greater code
> >> density from CISCs, even in the past.
> > <
> > Given that RISC-V compressed has similar code density as several of the
> > CISC chips, it is competing against, apparently there is no longer "such a
> > great distance" between CISC code density and RISC code density.
> > <
> > AND at this point one needs to refocus on how much work is encoded
> > in <how few of> the application instructions.
> Also why I am currently more in support of "limited variable length"
> encodings, say:
> 16/32/64/96, or 16/32/48/64/96
> Rather than fully variable length byte-oriented encodings.
<
I have never been a fan of fully variable length encodings--I saw the disaster
Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
VAX was overboard--although if there was some way to encode PDP-11
ISA such that you got 1 immediate and 1 displacement per instruction it
would have been a better design. On the whole:: IBM 360 is also pretty
tolerable ISA-wise (although I have no idea what they did to ISA in the
transformation to 64-bit Z-series.
<
I support 32-64-96-128-160-------------BUT
<
Everything comes in word (32-bit) containers-------------------AND
<
Everything Decode needs is found in the first word----------------AND
<
The variable length can be determined in 4 gates of delay and 30 total gates.
>
> The limited case provides nearly the same code density, but can be a lot
> easier and more efficient to decode.
>
> Granted, the most optimal encoding scheme within this space is more
> subject to debate.
>
Can we agree that code sizes that are within a handful of %-age points
are "essentially" equal ?
>
> Does not entirely avoid the "how much stuff can I fit into a 32 bit
> encoding?" issue, if the 32-bit encoding space is still the central hub
> that all of the other encodings revolve around.
<
It is not "how much stuff" you can get in, but in how few bits.

On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
> On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> > On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> > >> Marcus <m.de...@this.bitsnbites.eu> writes:
> > >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> > >>
> > >> The -Os results may not be representative of real-world programs, but
> > >> may be more informative wrt. instruction set density. If on
> > >> architecture A -O2 and -O3 unroll more than on architecture B, this
> > >> will look with your method like architecture A has less code density..
> > >> -Os should minimize these kinds of effects.
> > >>
> > >> Concerning "dynamic code density", if the purpose of code density is
> > >> to minimize I-cache misses, the way to go would be to measure I-cache
> > >> misses (maybe with a cache simulator to get comparable cache sizes and
> > >> get rid of prefetching artifacts; and with different I-cache sizes to
> > >> see how consistent the difference is). Instruction fetch bandwidth is
> > >> another interesting issue, with a few problems: Do you account
> > >> instruction fetches from mispredictions, or extra bytes fetched behind
> > >> a taken branch?
> > > <
> > > a) the purpose of greater code density is also to execute fewer instructions.
> > > <
> > > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > > I, personally, want to chip away at that 50% adder, and adding constants
> > > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > > only executes 75%-79% as many instructions as RISC-V.
> > Similar probably for things like Jumbo encodings in my case, which can
> > somewhat cut down on the need for constant loads.
> > >>
> > >> I wonder if there is really substance to the myth of greater code
> > >> density from CISCs, even in the past.
> > > <
> > > Given that RISC-V compressed has similar code density as several of the
> > > CISC chips, it is competing against, apparently there is no longer "such a
> > > great distance" between CISC code density and RISC code density.
> > > <
> > > AND at this point one needs to refocus on how much work is encoded
> > > in <how few of> the application instructions.
> > Also why I am currently more in support of "limited variable length"
> > encodings, say:
> > 16/32/64/96, or 16/32/48/64/96
> > Rather than fully variable length byte-oriented encodings.
> <
> I have never been a fan of fully variable length encodings--I saw the disaster
> Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
> VAX was overboard--although if there was some way to encode PDP-11
> ISA such that you got 1 immediate and 1 displacement per instruction it
> would have been a better design. On the whole:: IBM 360 is also pretty
> tolerable ISA-wise (although I have no idea what they did to ISA in the
> transformation to 64-bit Z-series.
> <
> I support 32-64-96-128-160-------------BUT
> <
> Everything comes in word (32-bit) containers-------------------AND
> <
> Everything Decode needs is found in the first word----------------AND
> <
> The variable length can be determined in 4 gates of delay and 30 total gates.
> >
> > The limited case provides nearly the same code density, but can be a lot
> > easier and more efficient to decode.
> >
> > Granted, the most optimal encoding scheme within this space is more
> > subject to debate.
> >
> Can we agree that code sizes that are within a handful of %-age points
> are "essentially" equal ?
> >
> > Does not entirely avoid the "how much stuff can I fit into a 32 bit
> > encoding?" issue, if the 32-bit encoding space is still the central hub
> > that all of the other encodings revolve around.
> <
> It is not "how much stuff" you can get in, but in how few bits.

The FPGA tools and the ASIC tools also offer settings for area versus speed?
And the degree (effort) to which the tools optimize in these directions?
AFAIK mature language compilers do also, although have not seen effort settings for compilers.
It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
The 32X being faster to decode and process, and the 8X offering the best code density.
(the holy grail being a high density ISA the serves both needs)
Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
both have and effect on code density.

With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
decode and extraction could get complicated (eg slow)?

RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
64-bit instructions).
"the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
Introduction to the iAPX 432 Architecture 1981 page 3-9 :((

On Monday, December 5, 2022 at 7:17:51 PM UTC-6, JimBrakefield wrote:
> On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
> > On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> > > On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > > > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> > > >> Marcus <m.de...@this.bitsnbites.eu> writes:
> > > >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> > > >>
> > > >> The -Os results may not be representative of real-world programs, but
> > > >> may be more informative wrt. instruction set density. If on
> > > >> architecture A -O2 and -O3 unroll more than on architecture B, this
> > > >> will look with your method like architecture A has less code density.
> > > >> -Os should minimize these kinds of effects.
> > > >>
> > > >> Concerning "dynamic code density", if the purpose of code density is
> > > >> to minimize I-cache misses, the way to go would be to measure I-cache
> > > >> misses (maybe with a cache simulator to get comparable cache sizes and
> > > >> get rid of prefetching artifacts; and with different I-cache sizes to
> > > >> see how consistent the difference is). Instruction fetch bandwidth is
> > > >> another interesting issue, with a few problems: Do you account
> > > >> instruction fetches from mispredictions, or extra bytes fetched behind
> > > >> a taken branch?
> > > > <
> > > > a) the purpose of greater code density is also to execute fewer instructions.
> > > > <
> > > > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > > > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > > > I, personally, want to chip away at that 50% adder, and adding constants
> > > > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > > > only executes 75%-79% as many instructions as RISC-V.
> > > Similar probably for things like Jumbo encodings in my case, which can
> > > somewhat cut down on the need for constant loads.
> > > >>
> > > >> I wonder if there is really substance to the myth of greater code
> > > >> density from CISCs, even in the past.
> > > > <
> > > > Given that RISC-V compressed has similar code density as several of the
> > > > CISC chips, it is competing against, apparently there is no longer "such a
> > > > great distance" between CISC code density and RISC code density.
> > > > <
> > > > AND at this point one needs to refocus on how much work is encoded
> > > > in <how few of> the application instructions.
> > > Also why I am currently more in support of "limited variable length"
> > > encodings, say:
> > > 16/32/64/96, or 16/32/48/64/96
> > > Rather than fully variable length byte-oriented encodings.
> > <
> > I have never been a fan of fully variable length encodings--I saw the disaster
> > Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
> > VAX was overboard--although if there was some way to encode PDP-11
> > ISA such that you got 1 immediate and 1 displacement per instruction it
> > would have been a better design. On the whole:: IBM 360 is also pretty
> > tolerable ISA-wise (although I have no idea what they did to ISA in the
> > transformation to 64-bit Z-series.
> > <
> > I support 32-64-96-128-160-------------BUT
> > <
> > Everything comes in word (32-bit) containers-------------------AND
> > <
> > Everything Decode needs is found in the first word----------------AND
> > <
> > The variable length can be determined in 4 gates of delay and 30 total gates.
> > >
> > > The limited case provides nearly the same code density, but can be a lot
> > > easier and more efficient to decode.
> > >
> > > Granted, the most optimal encoding scheme within this space is more
> > > subject to debate.
> > >
> > Can we agree that code sizes that are within a handful of %-age points
> > are "essentially" equal ?
> > >
> > > Does not entirely avoid the "how much stuff can I fit into a 32 bit
> > > encoding?" issue, if the 32-bit encoding space is still the central hub
> > > that all of the other encodings revolve around.
> > <
> > It is not "how much stuff" you can get in, but in how few bits.
> The FPGA tools and the ASIC tools also offer settings for area versus speed?
> And the degree (effort) to which the tools optimize in these directions?
> AFAIK mature language compilers do also, although have not seen effort settings for compilers.
> It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
> The 32X being faster to decode and process, and the 8X offering the best code density.
<
32X means 32-bits ?
<
> (the holy grail being a high density ISA the serves both needs)
<
I seem to be within spitting distance of this...........
<
> Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
> both have and effect on code density.
<
In the not so distant past, the call and return from subroutines had excessive
"overhead"; making de-inlining unwise except when one is explicitly sacrificing
performance for density.
>
> With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
> decode and extraction could get complicated (eg slow)?
<
Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
<
It seems to me, when I faced this, that instructions with 2 immediates can ALWAYS
be done at compile time. And for a long time, my 1-operand instructions did not have
access to immediates {however a use case showed up and I added constants so that
<
CVTSF R7,#3 // R7 = 3.0D0
<
could be expressed in one 32-bit instruction.
>
> RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
> for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
> 64-bit instructions).
> "the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
> Introduction to the iAPX 432 Architecture 1981 page 3-9 :((
<
Very similar to the charge of the light brigade--and just as effective.

On Monday, December 5, 2022 at 7:56:57 PM UTC-6, MitchAlsup wrote:
> On Monday, December 5, 2022 at 7:17:51 PM UTC-6, JimBrakefield wrote:
> > On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
> > > On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> > > > On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > > > > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> > > > >> Marcus <m.de...@this.bitsnbites.eu> writes:
> > > > >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> > > > >>
> > > > >> The -Os results may not be representative of real-world programs, but
> > > > >> may be more informative wrt. instruction set density. If on
> > > > >> architecture A -O2 and -O3 unroll more than on architecture B, this
> > > > >> will look with your method like architecture A has less code density.
> > > > >> -Os should minimize these kinds of effects.
> > > > >>
> > > > >> Concerning "dynamic code density", if the purpose of code density is
> > > > >> to minimize I-cache misses, the way to go would be to measure I-cache
> > > > >> misses (maybe with a cache simulator to get comparable cache sizes and
> > > > >> get rid of prefetching artifacts; and with different I-cache sizes to
> > > > >> see how consistent the difference is). Instruction fetch bandwidth is
> > > > >> another interesting issue, with a few problems: Do you account
> > > > >> instruction fetches from mispredictions, or extra bytes fetched behind
> > > > >> a taken branch?
> > > > > <
> > > > > a) the purpose of greater code density is also to execute fewer instructions.
> > > > > <
> > > > > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > > > > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > > > > I, personally, want to chip away at that 50% adder, and adding constants
> > > > > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > > > > only executes 75%-79% as many instructions as RISC-V.
> > > > Similar probably for things like Jumbo encodings in my case, which can
> > > > somewhat cut down on the need for constant loads.
> > > > >>
> > > > >> I wonder if there is really substance to the myth of greater code
> > > > >> density from CISCs, even in the past.
> > > > > <
> > > > > Given that RISC-V compressed has similar code density as several of the
> > > > > CISC chips, it is competing against, apparently there is no longer "such a
> > > > > great distance" between CISC code density and RISC code density.
> > > > > <
> > > > > AND at this point one needs to refocus on how much work is encoded
> > > > > in <how few of> the application instructions.
> > > > Also why I am currently more in support of "limited variable length"
> > > > encodings, say:
> > > > 16/32/64/96, or 16/32/48/64/96
> > > > Rather than fully variable length byte-oriented encodings.
> > > <
> > > I have never been a fan of fully variable length encodings--I saw the disaster
> > > Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
> > > VAX was overboard--although if there was some way to encode PDP-11
> > > ISA such that you got 1 immediate and 1 displacement per instruction it
> > > would have been a better design. On the whole:: IBM 360 is also pretty
> > > tolerable ISA-wise (although I have no idea what they did to ISA in the
> > > transformation to 64-bit Z-series.
> > > <
> > > I support 32-64-96-128-160-------------BUT
> > > <
> > > Everything comes in word (32-bit) containers-------------------AND
> > > <
> > > Everything Decode needs is found in the first word----------------AND
> > > <
> > > The variable length can be determined in 4 gates of delay and 30 total gates.
> > > >
> > > > The limited case provides nearly the same code density, but can be a lot
> > > > easier and more efficient to decode.
> > > >
> > > > Granted, the most optimal encoding scheme within this space is more
> > > > subject to debate.
> > > >
> > > Can we agree that code sizes that are within a handful of %-age points
> > > are "essentially" equal ?
> > > >
> > > > Does not entirely avoid the "how much stuff can I fit into a 32 bit
> > > > encoding?" issue, if the 32-bit encoding space is still the central hub
> > > > that all of the other encodings revolve around.
> > > <
> > > It is not "how much stuff" you can get in, but in how few bits.
> > The FPGA tools and the ASIC tools also offer settings for area versus speed?
> > And the degree (effort) to which the tools optimize in these directions?
> > AFAIK mature language compilers do also, although have not seen effort settings for compilers.
> > It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
> > The 32X being faster to decode and process, and the 8X offering the best code density.
> <
> 32X means 32-bits ?
> <
> > (the holy grail being a high density ISA the serves both needs)
> <
> I seem to be within spitting distance of this...........
> <
> > Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
> > both have and effect on code density.
> <
> In the not so distant past, the call and return from subroutines had excessive
> "overhead"; making de-inlining unwise except when one is explicitly sacrificing
> performance for density.
> >
> > With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
> > decode and extraction could get complicated (eg slow)?
> <
> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> <
> It seems to me, when I faced this, that instructions with 2 immediates can ALWAYS
> be done at compile time. And for a long time, my 1-operand instructions did not have
> access to immediates {however a use case showed up and I added constants so that
> <
> CVTSF R7,#3 // R7 = 3.0D0
> <
> could be expressed in one 32-bit instruction.
> >
> > RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
> > for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
> > 64-bit instructions).
> > "the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
> > Introduction to the iAPX 432 Architecture 1981 page 3-9 :((
> <
> Very similar to the charge of the light brigade--and just as effective.

|> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
If the ISA supports various length instructions (exclusive of the immediate(s))
|> 32X means 32-bits ?
Yes, things are a multiple of 32 bits

On Monday, December 5, 2022 at 8:03:12 PM UTC-6, JimBrakefield wrote:
> On Monday, December 5, 2022 at 7:56:57 PM UTC-6, MitchAlsup wrote:
> > On Monday, December 5, 2022 at 7:17:51 PM UTC-6, JimBrakefield wrote:
> > > On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
> > > > On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> > > > > On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > > > > > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> > > > > >> Marcus <m.de...@this.bitsnbites.eu> writes:
> > > > > >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> > > > > >>
> > > > > >> The -Os results may not be representative of real-world programs, but
> > > > > >> may be more informative wrt. instruction set density. If on
> > > > > >> architecture A -O2 and -O3 unroll more than on architecture B, this
> > > > > >> will look with your method like architecture A has less code density.
> > > > > >> -Os should minimize these kinds of effects.
> > > > > >>
> > > > > >> Concerning "dynamic code density", if the purpose of code density is
> > > > > >> to minimize I-cache misses, the way to go would be to measure I-cache
> > > > > >> misses (maybe with a cache simulator to get comparable cache sizes and
> > > > > >> get rid of prefetching artifacts; and with different I-cache sizes to
> > > > > >> see how consistent the difference is). Instruction fetch bandwidth is
> > > > > >> another interesting issue, with a few problems: Do you account
> > > > > >> instruction fetches from mispredictions, or extra bytes fetched behind
> > > > > >> a taken branch?
> > > > > > <
> > > > > > a) the purpose of greater code density is also to execute fewer instructions.
> > > > > > <
> > > > > > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > > > > > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > > > > > I, personally, want to chip away at that 50% adder, and adding constants
> > > > > > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > > > > > only executes 75%-79% as many instructions as RISC-V.
> > > > > Similar probably for things like Jumbo encodings in my case, which can
> > > > > somewhat cut down on the need for constant loads.
> > > > > >>
> > > > > >> I wonder if there is really substance to the myth of greater code
> > > > > >> density from CISCs, even in the past.
> > > > > > <
> > > > > > Given that RISC-V compressed has similar code density as several of the
> > > > > > CISC chips, it is competing against, apparently there is no longer "such a
> > > > > > great distance" between CISC code density and RISC code density..
> > > > > > <
> > > > > > AND at this point one needs to refocus on how much work is encoded
> > > > > > in <how few of> the application instructions.
> > > > > Also why I am currently more in support of "limited variable length"
> > > > > encodings, say:
> > > > > 16/32/64/96, or 16/32/48/64/96
> > > > > Rather than fully variable length byte-oriented encodings.
> > > > <
> > > > I have never been a fan of fully variable length encodings--I saw the disaster
> > > > Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
> > > > VAX was overboard--although if there was some way to encode PDP-11
> > > > ISA such that you got 1 immediate and 1 displacement per instruction it
> > > > would have been a better design. On the whole:: IBM 360 is also pretty
> > > > tolerable ISA-wise (although I have no idea what they did to ISA in the
> > > > transformation to 64-bit Z-series.
> > > > <
> > > > I support 32-64-96-128-160-------------BUT
> > > > <
> > > > Everything comes in word (32-bit) containers-------------------AND
> > > > <
> > > > Everything Decode needs is found in the first word----------------AND
> > > > <
> > > > The variable length can be determined in 4 gates of delay and 30 total gates.
> > > > >
> > > > > The limited case provides nearly the same code density, but can be a lot
> > > > > easier and more efficient to decode.
> > > > >
> > > > > Granted, the most optimal encoding scheme within this space is more
> > > > > subject to debate.
> > > > >
> > > > Can we agree that code sizes that are within a handful of %-age points
> > > > are "essentially" equal ?
> > > > >
> > > > > Does not entirely avoid the "how much stuff can I fit into a 32 bit
> > > > > encoding?" issue, if the 32-bit encoding space is still the central hub
> > > > > that all of the other encodings revolve around.
> > > > <
> > > > It is not "how much stuff" you can get in, but in how few bits.
> > > The FPGA tools and the ASIC tools also offer settings for area versus speed?
> > > And the degree (effort) to which the tools optimize in these directions?
> > > AFAIK mature language compilers do also, although have not seen effort settings for compilers.
> > > It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
> > > The 32X being faster to decode and process, and the 8X offering the best code density.
> > <
> > 32X means 32-bits ?
> > <
> > > (the holy grail being a high density ISA the serves both needs)
> > <
> > I seem to be within spitting distance of this...........
> > <
> > > Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
> > > both have and effect on code density.
> > <
> > In the not so distant past, the call and return from subroutines had excessive
> > "overhead"; making de-inlining unwise except when one is explicitly sacrificing
> > performance for density.
> > >
> > > With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
> > > decode and extraction could get complicated (eg slow)?
> > <
> > Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> > <
> > It seems to me, when I faced this, that instructions with 2 immediates can ALWAYS
> > be done at compile time. And for a long time, my 1-operand instructions did not have
> > access to immediates {however a use case showed up and I added constants so that
> > <
> > CVTSF R7,#3 // R7 = 3.0D0
> > <
> > could be expressed in one 32-bit instruction.
> > >
> > > RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
> > > for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
> > > 64-bit instructions).
> > > "the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
> > > Introduction to the iAPX 432 Architecture 1981 page 3-9 :((
> > <
> > Very similar to the charge of the light brigade--and just as effective.
>
> |> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> If the ISA supports various length instructions (exclusive of the immediate(s))
<
That is not an explanation. What I want is justification for "having the ability" to
encode more than 1 immediate (constant to a calculation) and/or more than 1
displacement (constant used in address generation) in a single instruction. Sure
lots of the PDP-11 and VAX variants allowed for this--but why would a compiler
ever defer to execution time that which can be performed at compile time ??
<
To a certain extent this gets right at the heart of the RISC-CISC debate. The CISC
guys might say--it comes for free why not allow it ? The RISC guys would retort--
This just shows that your encoding scheme has excess entropy. Furthermore;
providing no more than 1 immediate and 1 displacement PREVENTS doing stupid
stuff to the ISA encoding (something VAX missed by a mile.)
<
> |> 32X means 32-bits ?
> Yes, things are a multiple of 32 bits
<

On Monday, December 5, 2022 at 8:33:12 PM UTC-6, MitchAlsup wrote:
> On Monday, December 5, 2022 at 8:03:12 PM UTC-6, JimBrakefield wrote:
> > On Monday, December 5, 2022 at 7:56:57 PM UTC-6, MitchAlsup wrote:
> > > On Monday, December 5, 2022 at 7:17:51 PM UTC-6, JimBrakefield wrote:
> > > > On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
> > > > > On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
> > > > > > On 12/4/2022 1:46 PM, MitchAlsup wrote:
> > > > > > > On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
> > > > > > >> Marcus <m.de...@this.bitsnbites.eu> writes:
> > > > > > >>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
> > > > > > >>
> > > > > > >> The -Os results may not be representative of real-world programs, but
> > > > > > >> may be more informative wrt. instruction set density. If on
> > > > > > >> architecture A -O2 and -O3 unroll more than on architecture B, this
> > > > > > >> will look with your method like architecture A has less code density.
> > > > > > >> -Os should minimize these kinds of effects.
> > > > > > >>
> > > > > > >> Concerning "dynamic code density", if the purpose of code density is
> > > > > > >> to minimize I-cache misses, the way to go would be to measure I-cache
> > > > > > >> misses (maybe with a cache simulator to get comparable cache sizes and
> > > > > > >> get rid of prefetching artifacts; and with different I-cache sizes to
> > > > > > >> see how consistent the difference is). Instruction fetch bandwidth is
> > > > > > >> another interesting issue, with a few problems: Do you account
> > > > > > >> instruction fetches from mispredictions, or extra bytes fetched behind
> > > > > > >> a taken branch?
> > > > > > > <
> > > > > > > a) the purpose of greater code density is also to execute fewer instructions.
> > > > > > > <
> > > > > > > In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
> > > > > > > 50% more instructions at 6× the frequency for a 4× performance advantage.
> > > > > > > I, personally, want to chip away at that 50% adder, and adding constants
> > > > > > > to a rather std RISC instruction set has given a 25% advantage. My 66000
> > > > > > > only executes 75%-79% as many instructions as RISC-V.
> > > > > > Similar probably for things like Jumbo encodings in my case, which can
> > > > > > somewhat cut down on the need for constant loads.
> > > > > > >>
> > > > > > >> I wonder if there is really substance to the myth of greater code
> > > > > > >> density from CISCs, even in the past.
> > > > > > > <
> > > > > > > Given that RISC-V compressed has similar code density as several of the
> > > > > > > CISC chips, it is competing against, apparently there is no longer "such a
> > > > > > > great distance" between CISC code density and RISC code density.
> > > > > > > <
> > > > > > > AND at this point one needs to refocus on how much work is encoded
> > > > > > > in <how few of> the application instructions.
> > > > > > Also why I am currently more in support of "limited variable length"
> > > > > > encodings, say:
> > > > > > 16/32/64/96, or 16/32/48/64/96
> > > > > > Rather than fully variable length byte-oriented encodings.
> > > > > <
> > > > > I have never been a fan of fully variable length encodings--I saw the disaster
> > > > > Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
> > > > > VAX was overboard--although if there was some way to encode PDP-11
> > > > > ISA such that you got 1 immediate and 1 displacement per instruction it
> > > > > would have been a better design. On the whole:: IBM 360 is also pretty
> > > > > tolerable ISA-wise (although I have no idea what they did to ISA in the
> > > > > transformation to 64-bit Z-series.
> > > > > <
> > > > > I support 32-64-96-128-160-------------BUT
> > > > > <
> > > > > Everything comes in word (32-bit) containers-------------------AND
> > > > > <
> > > > > Everything Decode needs is found in the first word----------------AND
> > > > > <
> > > > > The variable length can be determined in 4 gates of delay and 30 total gates.
> > > > > >
> > > > > > The limited case provides nearly the same code density, but can be a lot
> > > > > > easier and more efficient to decode.
> > > > > >
> > > > > > Granted, the most optimal encoding scheme within this space is more
> > > > > > subject to debate.
> > > > > >
> > > > > Can we agree that code sizes that are within a handful of %-age points
> > > > > are "essentially" equal ?
> > > > > >
> > > > > > Does not entirely avoid the "how much stuff can I fit into a 32 bit
> > > > > > encoding?" issue, if the 32-bit encoding space is still the central hub
> > > > > > that all of the other encodings revolve around.
> > > > > <
> > > > > It is not "how much stuff" you can get in, but in how few bits.
> > > > The FPGA tools and the ASIC tools also offer settings for area versus speed?
> > > > And the degree (effort) to which the tools optimize in these directions?
> > > > AFAIK mature language compilers do also, although have not seen effort settings for compilers.
> > > > It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
> > > > The 32X being faster to decode and process, and the 8X offering the best code density.
> > > <
> > > 32X means 32-bits ?
> > > <
> > > > (the holy grail being a high density ISA the serves both needs)
> > > <
> > > I seem to be within spitting distance of this...........
> > > <
> > > > Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
> > > > both have and effect on code density.
> > > <
> > > In the not so distant past, the call and return from subroutines had excessive
> > > "overhead"; making de-inlining unwise except when one is explicitly sacrificing
> > > performance for density.
> > > >
> > > > With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
> > > > decode and extraction could get complicated (eg slow)?
> > > <
> > > Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> > > <
> > > It seems to me, when I faced this, that instructions with 2 immediates can ALWAYS
> > > be done at compile time. And for a long time, my 1-operand instructions did not have
> > > access to immediates {however a use case showed up and I added constants so that
> > > <
> > > CVTSF R7,#3 // R7 = 3.0D0
> > > <
> > > could be expressed in one 32-bit instruction.
> > > >
> > > > RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
> > > > for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
> > > > 64-bit instructions).
> > > > "the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
> > > > Introduction to the iAPX 432 Architecture 1981 page 3-9 :((
> > > <
> > > Very similar to the charge of the light brigade--and just as effective.
> >
> > |> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> > If the ISA supports various length instructions (exclusive of the immediate(s))
> <
> That is not an explanation. What I want is justification for "having the ability" to
> encode more than 1 immediate (constant to a calculation) and/or more than 1
> displacement (constant used in address generation) in a single instruction. Sure
> lots of the PDP-11 and VAX variants allowed for this--but why would a compiler
> ever defer to execution time that which can be performed at compile time ??
> <
Having a variable length instruction plus variable length immediate and variable length offset
That said, don't think is is a good idea: too many shifters and field extractors necessarily serially connected.
Would suggest at most two instruction sizes and one variable length "immediate/offset"
In my "planning" several things force a two step/two clock instruction decode. With three variations, a three step decode.
If the alignments are good, then an opportunistic one step decode.
> <
> To a certain extent this gets right at the heart of the RISC-CISC debate. The CISC
> guys might say--it comes for free why not allow it ? The RISC guys would retort--
> This just shows that your encoding scheme has excess entropy. Furthermore;
> providing no more than 1 immediate and 1 displacement PREVENTS doing stupid
> stuff to the ISA encoding (something VAX missed by a mile.)
> <
Given today's transistor budgets it would not be a surprise if there are circuits here and there that look for
opportunities to shortcut instruction execution (like OR Dn,Rn,Sn being a NOP)?
As for entropy, have seen examples that for a given program its encoded entropy is far less than the capability of the ISA.
E.g. the compiler does not fully exploit the ISA or that the ISA is incapable of densely encoding the program.

On Monday, December 5, 2022 at 9:05:14 PM UTC-6, JimBrakefield wrote:
> On Monday, December 5, 2022 at 8:33:12 PM UTC-6, MitchAlsup wrote:
> > On Monday, December 5, 2022 at 8:03:12 PM UTC-6, JimBrakefield wrote:

> > > |> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> > > If the ISA supports various length instructions (exclusive of the immediate(s))
> > <
> > That is not an explanation. What I want is justification for "having the ability" to
> > encode more than 1 immediate (constant to a calculation) and/or more than 1
> > displacement (constant used in address generation) in a single instruction. Sure
> > lots of the PDP-11 and VAX variants allowed for this--but why would a compiler
> > ever defer to execution time that which can be performed at compile time ??
> > <
> Having a variable length instruction plus variable length immediate and variable length offset
<
This is not a sentence or a question.
<
> That said, don't think is is a good idea: too many shifters and field extractors necessarily serially connected.
<
All of the things you want to extract are in the 1st word of the variable length instruction.
I named this first word the "instruction-specifier" (note: with hyphen). So, we are beyond that.
<
> Would suggest at most two instruction sizes and one variable length "immediate/offset"
<
I suggest that there is exactly 1 size instruction-specifier with essentially fixed field
positions. The variable length is entirely present to deliver constants into execution.
<
> In my "planning" several things force a two step/two clock instruction decode. With three variations, a three step decode.
<
When one considers that an SRAM (the things caches are composed from) need their
address to meet setup time to a Flip-Flop at the SRAM macro, and you can't even see
the data until after a flip-flop that captures the SRAM output data, you can't even start
tag comparison until the cycle following the Cache read. This, all by itself, essentially
mandates a 2 cycle decode:: you don't know which way contains the data until 6-gates
into the cycle, and by the time you have buffered up the control signal and driven the
select lines to out gate data the hitting data, you are well past ½ cycle into the first
DECODE cycle (which I call PARSE).
<
In effect, the 5 stage RISC-V pipeline is accessing the SRAM macros on both phases of
the clock. You can do this when you spend lots of effort in the "clock tree" or are willing
to run at 65% of the technologies maximal frequency.
<
> If the alignments are good, then an opportunistic one step decode.
> > <
> > To a certain extent this gets right at the heart of the RISC-CISC debate. The CISC
> > guys might say--it comes for free why not allow it ? The RISC guys would retort--
> > This just shows that your encoding scheme has excess entropy. Furthermore;
> > providing no more than 1 immediate and 1 displacement PREVENTS doing stupid
> > stuff to the ISA encoding (something VAX missed by a mile.)
> > <
> Given today's transistor budgets it would not be a surprise if there are circuits here and there that look for
> opportunities to shortcut instruction execution (like OR Dn,Rn,Sn being a NOP)?
<
Why would you want a NoOp in your ISA ???
A NoOp does nothing,
Instructions are supposed to be a series of state changes to the register+memory
......image of the application,
A NoOp does not change any state,
Why should it even exist ??
{We are not filling in delay slots any more)
A properly designed ISA does not need to have the ability to say "do nothing".
Or perhaps you could give an example as to why one would both want to emit
(from the compiler) and to perform (in the HW) a NoOp instruction.
<
But prehaps you meant something more like a::
<
JMP R~0 // is likely an indirect jump
while
JMP R0 // is likely a return
<
> As for entropy, have seen examples that for a given program its encoded entropy is far less than the capability of the ISA.
<
That is not what we are talking about here. We ae talking about why you should (or not) have the ability
to specify more than 1 immediate and more than 1 displacement.
<
> E.g. the compiler does not fully exploit the ISA or that the ISA is incapable of densely encoding the program.
<
Then fix the compiler,
don't
t fix the ISA to make up for a bad compiler.

MitchAlsup <MitchAlsup@aol.com> schrieb:

> Can you explain why one would need more than 1 immediate and 1
> displacement per instruction ??

Not displacement, but... for instructions with three operands, it
could be useful. For example,

double foo(double x)
{ return x*1.2 - 0.7;
}

is currently

mov r2,#0x3FF3333333333333
fmac r1,r1,r2,#0xBFE6666666666666
ret

On Tuesday, December 6, 2022 at 1:31:24 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:

>A NoOp does not change any state,
>Why should it even exist ??

I always include a NOP instruction in the ISA. It can be used to provide inline
arguments assuming the NOP has a payload area. It can be used as a debug
marker, annotating the code. It could be used to leave an area of code empty
so that it can be replaced by other code at runtime.

On 06.12.2022 12:01, robf...@gmail.com wrote:
> On Tuesday, December 6, 2022 at 1:31:24 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>
>> A NoOp does not change any state,
>> Why should it even exist ??
>
> I always include a NOP instruction in the ISA. It can be used to provide inline
> arguments assuming the NOP has a payload area. It can be used as a debug
> marker, annotating the code. It could be used to leave an area of code empty
> so that it can be replaced by other code at runtime.

Any orthogonal instruction set provides lots of NOP equivalents, e.g.

ori Rx, Rx, #0
or Rx, Rx, Rx
and Rx, Rx, Rx
addi Rx, Rx, #0
rotr Rx, Rx, #0 / rotr Rx, Rx, #64

On Tuesday, December 6, 2022 at 6:17:44 AM UTC-5, Bernd Linsel wrote:
> On 06.12.2022 12:01, robf...@gmail.com wrote:
> > On Tuesday, December 6, 2022 at 1:31:24 AM UTC-5, Thomas Koenig wrote:
> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >
> >> A NoOp does not change any state,
> >> Why should it even exist ??
> >
> > I always include a NOP instruction in the ISA. It can be used to provide inline
> > arguments assuming the NOP has a payload area. It can be used as a debug
> > marker, annotating the code. It could be used to leave an area of code empty
> > so that it can be replaced by other code at runtime.
> Any orthogonal instruction set provides lots of NOP equivalents, e.g.
>
> ori Rx, Rx, #0
> or Rx, Rx, Rx
> and Rx, Rx, Rx
> addi Rx, Rx, #0
> rotr Rx, Rx, #0 / rotr Rx, Rx, #64

I suppose it could be done with NOP equivalent instructions, but it is more
restrictive. Multi-word NOPs can allow multiple entry points. A 32-bit NOP instruction
with a six-bit opcode and a 26-bit payload gives 2^26 possible NOPs. A lot of NOPs
might be wanted to perform program tracing. NOPs with arbitrary payloads allow
embedding a program within a program. A 26-bit instruction set could be designed to
fit into NOPs. Could be used to verify the integrity of a program.

MitchAlsup wrote:
> <
> Why would you want a NoOp in your ISA ???
> A NoOp does nothing,

Code alignment padding.
It was a common optimization to align routine entry and
loop entries to cache boundaries.

For self modifying code, I can see having an instruction 'hole' that one
wants to generate a single instruction into, but there are different
generated instructions so it may need to pad out to the 'hole' size.

Some ISA's have multiple sized Nop's so they can pad
with the minimum number of wasted decode cycles.

On 12/6/2022 8:12 AM, EricP wrote:
> MitchAlsup wrote:
>> <
>> Why would you want a NoOp in your ISA ???
>> A NoOp does nothing,
>
> Code alignment padding.
> It was a common optimization to align routine entry and
> loop entries to cache boundaries.
>
> For self modifying code, I can see having an instruction 'hole' that one
> wants to generate a single instruction into, but there are different
> generated instructions so it may need to pad out to the 'hole' size.
>
> Some ISA's have multiple sized Nop's so they can pad
> with the minimum number of wasted decode cycles.
>

Yeah, a NOP is pretty standard feature:
Allows for aligning stuff;
Allows for spots for the linker or loader to patch up certain
instruction sequences if needed, ...

More debatable though is whether to have a dedicated NOP instruction, or
merely define some other special case (such as "OR R0, R0, R0" as the NOP).

....

On Tuesday, December 6, 2022 at 4:59:56 PM UTC-6, BGB wrote:
> On 12/6/2022 8:12 AM, EricP wrote:
> > MitchAlsup wrote:
> >> <
> >> Why would you want a NoOp in your ISA ???
> >> A NoOp does nothing,
> >
> > Code alignment padding.
> > It was a common optimization to align routine entry and
> > loop entries to cache boundaries.
> >
> > For self modifying code, I can see having an instruction 'hole' that one
> > wants to generate a single instruction into, but there are different
> > generated instructions so it may need to pad out to the 'hole' size.
> >
> > Some ISA's have multiple sized Nop's so they can pad
> > with the minimum number of wasted decode cycles.
<
A sign that something is wrong with that ISA.
> >
> Yeah, a NOP is pretty standard feature:
<
In the past, certainly, in the future ???
<
> Allows for aligning stuff;
<
With 32-bit extensions, there is no code misalignment in My 66000,
and if you try to misalign IP you take an exception.
<
> Allows for spots for the linker or loader to patch up certain
> instruction sequences if needed, ...
<
These places come out of the ASM in 64-bit constant form, and the linker
can shrink them if the constant fits in a smaller footprint.
>
>
> More debatable though is whether to have a dedicated NOP instruction, or
> merely define some other special case (such as "OR R0, R0, R0" as the NOP).
>
Every ISA has some way to "doing no work" while executing instructions;
one time I was forced to wait for an external signal in x8085 ASM and I found
back-to-back XTHLs optimal for wasting time. 1-byte instruction takes 12
cycles to execute. Probably not what the architect had expected for the
use of that instruction.
<
But the question is whether there should be an explicit OpCode for NoOp
(or more than one) is a lot different that whether it is possible to do noting
by executing an instruction.
> ...

On 12/5/2022 7:56 PM, MitchAlsup wrote:
> On Monday, December 5, 2022 at 7:17:51 PM UTC-6, JimBrakefield wrote:
>> On Monday, December 5, 2022 at 6:37:22 PM UTC-6, MitchAlsup wrote:
>>> On Monday, December 5, 2022 at 5:33:25 PM UTC-6, BGB wrote:
>>>> On 12/4/2022 1:46 PM, MitchAlsup wrote:
>>>>> On Sunday, December 4, 2022 at 4:44:31 AM UTC-6, Anton Ertl wrote:
>>>>>> Marcus <m.de...@this.bitsnbites.eu> writes:
>>>>>>> https://www.bitsnbites.eu/cisc-vs-risc-code-density/
>>>>>>
>>>>>> The -Os results may not be representative of real-world programs, but
>>>>>> may be more informative wrt. instruction set density. If on
>>>>>> architecture A -O2 and -O3 unroll more than on architecture B, this
>>>>>> will look with your method like architecture A has less code density.
>>>>>> -Os should minimize these kinds of effects.
>>>>>>
>>>>>> Concerning "dynamic code density", if the purpose of code density is
>>>>>> to minimize I-cache misses, the way to go would be to measure I-cache
>>>>>> misses (maybe with a cache simulator to get comparable cache sizes and
>>>>>> get rid of prefetching artifacts; and with different I-cache sizes to
>>>>>> see how consistent the difference is). Instruction fetch bandwidth is
>>>>>> another interesting issue, with a few problems: Do you account
>>>>>> instruction fetches from mispredictions, or extra bytes fetched behind
>>>>>> a taken branch?
>>>>> <
>>>>> a) the purpose of greater code density is also to execute fewer instructions.
>>>>> <
>>>>> In the early 1980s, Mark Horowitz stated that <Stanford> MIPS executed
>>>>> 50% more instructions at 6× the frequency for a 4× performance advantage.
>>>>> I, personally, want to chip away at that 50% adder, and adding constants
>>>>> to a rather std RISC instruction set has given a 25% advantage. My 66000
>>>>> only executes 75%-79% as many instructions as RISC-V.
>>>> Similar probably for things like Jumbo encodings in my case, which can
>>>> somewhat cut down on the need for constant loads.
>>>>>>
>>>>>> I wonder if there is really substance to the myth of greater code
>>>>>> density from CISCs, even in the past.
>>>>> <
>>>>> Given that RISC-V compressed has similar code density as several of the
>>>>> CISC chips, it is competing against, apparently there is no longer "such a
>>>>> great distance" between CISC code density and RISC code density.
>>>>> <
>>>>> AND at this point one needs to refocus on how much work is encoded
>>>>> in <how few of> the application instructions.
>>>> Also why I am currently more in support of "limited variable length"
>>>> encodings, say:
>>>> 16/32/64/96, or 16/32/48/64/96
>>>> Rather than fully variable length byte-oriented encodings.
>>> <
>>> I have never been a fan of fully variable length encodings--I saw the disaster
>>> Intel 432 was first hand. PDP-11 (and 68K) were pretty tolerable ISA-wise,
>>> VAX was overboard--although if there was some way to encode PDP-11
>>> ISA such that you got 1 immediate and 1 displacement per instruction it
>>> would have been a better design. On the whole:: IBM 360 is also pretty
>>> tolerable ISA-wise (although I have no idea what they did to ISA in the
>>> transformation to 64-bit Z-series.
>>> <
>>> I support 32-64-96-128-160-------------BUT
>>> <
>>> Everything comes in word (32-bit) containers-------------------AND
>>> <
>>> Everything Decode needs is found in the first word----------------AND
>>> <
>>> The variable length can be determined in 4 gates of delay and 30 total gates.
>>>>
>>>> The limited case provides nearly the same code density, but can be a lot
>>>> easier and more efficient to decode.
>>>>
>>>> Granted, the most optimal encoding scheme within this space is more
>>>> subject to debate.
>>>>
>>> Can we agree that code sizes that are within a handful of %-age points
>>> are "essentially" equal ?
>>>>
>>>> Does not entirely avoid the "how much stuff can I fit into a 32 bit
>>>> encoding?" issue, if the 32-bit encoding space is still the central hub
>>>> that all of the other encodings revolve around.
>>> <
>>> It is not "how much stuff" you can get in, but in how few bits.
>> The FPGA tools and the ASIC tools also offer settings for area versus speed?
>> And the degree (effort) to which the tools optimize in these directions?
>> AFAIK mature language compilers do also, although have not seen effort settings for compilers.
>> It would be great if an ISA supports both blocked (32X) and variable length immediates/constants/displacements
>> The 32X being faster to decode and process, and the 8X offering the best code density.
> <
> 32X means 32-bits ?
> <
>> (the holy grail being a high density ISA the serves both needs)
> <
> I seem to be within spitting distance of this...........

Likewise.

Even without LZ4 compressing the binaries, I still seem to be getting
somewhat better code density than x86-64.

Still not quite as good as Thumb2 though.

LZ4 compressed binaries are smaller than Thumb2 binaries, but LZ4
compression also works well on Thumb2...

In my own testing, Thumb2 tended to be the front-runner in terms of code
density (seems to beat out i386, RVC, and SH-4; then typically followed
by x86-64 and ARMv8).

As noted, I have both speed and size optimization settings, since
slightly different tradeoffs need to be made.

Originally, BJX2 started out with 16-bit origins, but a few iterations
later had switched to 32-bit as the primary ISA with 16-bit encodings
serving more as a space-saving subset.

Also 32-bit ended getting a lot more emphasis, because a "shuffle and
bundle" strategy works a lit better with fixed-length 32-bit
instructions, but starts to fall on its face when freely variable length
encodings are used (this would add significant implementation complexity
to this part of the compiler).

> <
>> Not the whole story, as subroutine inlining and depth of code factoring (e.g. using lots of small subroutines)
>> both have and effect on code density.
> <
> In the not so distant past, the call and return from subroutines had excessive
> "overhead"; making de-inlining unwise except when one is explicitly sacrificing
> performance for density.

I still don't have inline functions, FWIW.

>>
>> With potential for two or three variable length items per instruction (instruction length, 1st immediate, 2nd immediate)
>> decode and extraction could get complicated (eg slow)?
> <
> Can you explain why one would need more than 1 immediate and 1 displacement per instruction ??
> <
> It seems to me, when I faced this, that instructions with 2 immediates can ALWAYS
> be done at compile time. And for a long time, my 1-operand instructions did not have
> access to immediates {however a use case showed up and I added constants so that
> <
> CVTSF R7,#3 // R7 = 3.0D0
> <
> could be expressed in one 32-bit instruction.

I seem to be getting along pretty OK with only a single immediate (with
displacements also being considered a type of immediate).

Instructions with both an immediate and displacement, or with two
immediate values, etc. Thus far haven't really seemed like a worthwhile
tradeoff.

>>
>> RE the Intel 432: fine to have variable bit length fields, but not at the expense of the vast majority of code. Stretch had provision
>> for variable bit length fields in memory, but also had the word size references for the majority of cases (using both 32-bit and
>> 64-bit instructions).
>> "the instructions are bit-variable in length and are not constrained to start or end on byte or word boundaries"
>> Introduction to the iAPX 432 Architecture 1981 page 3-9 :((
> <
> Very similar to the charge of the light brigade--and just as effective.

The instruction encoding as a bitstream is "likely just not worth it".

Though, does sort of remind me that I had also been working on/off a
little recently on a possible idea for a way to make a Huffman decoder
somewhat faster on BJX2 (I suspect its effectiveness would be diminished
on x86-64, as decoding 4 symbols in parallel requires more variables
than x86-64 has registers; one would be limited to two symbols in
parallel to fit it into registers).

Unique NOPs can be used to trigger breakpoints in the logic analyzer / simulator. I have
been thinking about incorporating NOP tracing in the processor trace. Rather than record
all the branches encountered, just a few NOPs could be recorded.

I used to build character strings for debugging while a program was running to tell which
paths of execution the program took. I could stop the program and see if it built a particular
string like “ABCDHIJK” which told me exactly where the program went.

A question I have is whether it is worthwhile to reserve a couple of opcode patterns to
support the simulator. Many simulators have an ‘END’ pseudo instruction which is not part
of the ISA but useful to the simulator. A reserved pattern for external tools.

If the presence of NOPs as dedicated NOPs is debatable, then why not include one in the ISA?
Most of the time there is plenty of opcode space for a NOP and they do not take many gates
to support.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, December 6, 2022 at 4:59:56 PM UTC-6, BGB wrote:
>> On 12/6/2022 8:12 AM, EricP wrote:
>> > MitchAlsup wrote:
>> >> <
>> >> Why would you want a NoOp in your ISA ???
>> >> A NoOp does nothing,
>> >
>> > Code alignment padding.
>> > It was a common optimization to align routine entry and
>> > loop entries to cache boundaries.
>> >
>> > For self modifying code, I can see having an instruction 'hole' that one
>> > wants to generate a single instruction into, but there are different
>> > generated instructions so it may need to pad out to the 'hole' size.
>> >
>> > Some ISA's have multiple sized Nop's so they can pad
>> > with the minimum number of wasted decode cycles.
><
>A sign that something is wrong with that ISA.
>> >
>> Yeah, a NOP is pretty standard feature:
><
>In the past, certainly, in the future ???
><
>> Allows for aligning stuff;
><
>With 32-bit extensions, there is no code misalignment in My 66000,
>and if you try to misalign IP you take an exception.
><
>> Allows for spots for the linker or loader to patch up certain
>> instruction sequences if needed, ...
><
>These places come out of the ASM in 64-bit constant form, and the linker
>can shrink them if the constant fits in a smaller footprint.
>>
>>
>> More debatable though is whether to have a dedicated NOP instruction, or
>> merely define some other special case (such as "OR R0, R0, R0" as the NOP).
>>
>Every ISA has some way to "doing no work" while executing instructions;

ARM64 has WFI and WFE, Intel/AMD have PAUSE and MWAIT. They have the
benefit of signaling the core that it can enter a lower-power state.

>But the question is whether there should be an explicit OpCode for NoOp
>(or more than one) is a lot different that whether it is possible to do noting
>by executing an instruction.
>> ...

Both of the above have explicit NOP instructions; which on intel are often
generated by compilers to align code to specific address constraints.

ARM64 has a range of "HINT" instructions; if a hint isn't supported
by an implementation it becomes a NOP.

"robf...@gmail.com" <robfi680@gmail.com> writes:
>Unique NOPs can be used to trigger breakpoints in the logic analyzer / simu=
>lator. I have
>been thinking about incorporating NOP tracing in the processor trace. Rathe=
>r than record
>all the branches encountered, just a few NOPs could be recorded.

Many processors use the intruction pointer/program counter as the
trigger for on-chip/JTAG logical analyzers, or have a instruction word
match register programmed to match a particular instruction bit pattern
(or pattern + mask to trap on a group of instructions).

>
>A question I have is whether it is worthwhile to reserve a couple of opcode=
> patterns to
>support the simulator. Many simulators have an =E2=80=98END=E2=80=99 pseudo=
> instruction which is not part
>of the ISA but useful to the simulator. A reserved pattern for external too=
>ls.

Several commercial and proprietary SoC simulators designate a rarely used
instruction to back-door to the host running the simulator. Can provide
paravirtualization capabilities such as access to the host file system
or 'stdout' for bare-metal applications running on the simulator, or
in one case, the code being simulated can actually send arbitrary commands
to the simulator, such as commands to start logging various actions
at a certain point (e.g. before executing a sequence of simulated
instructions).

>
>If the presence of NOPs as dedicated NOPs is debatable, then why not includ=
>e one in the ISA?
>Most of the time there is plenty of opcode space for a NOP and they do not =
>take many gates
>to support.

Indeed.

On Tuesday, December 6, 2022 at 5:53:29 PM UTC-6, robf...@gmail.com wrote:
> Unique NOPs can be used to trigger breakpoints in the logic analyzer / simulator. I have
> been thinking about incorporating NOP tracing in the processor trace. Rather than record
> all the branches encountered, just a few NOPs could be recorded.
>
> I used to build character strings for debugging while a program was running to tell which
> paths of execution the program took. I could stop the program and see if it built a particular
> string like “ABCDHIJK” which told me exactly where the program went.
>
> A question I have is whether it is worthwhile to reserve a couple of opcode patterns to
> support the simulator. Many simulators have an ‘END’ pseudo instruction which is not part
> of the ISA but useful to the simulator. A reserved pattern for external tools.
<
I can see a purpose of an instruction that halts the pipeline so a HW debugger could scan out
the current state--but this is not a NoOp--and that OpCode probably does not ship to customers.
>
> If the presence of NOPs as dedicated NOPs is debatable, then why not include one in the ISA?
> Most of the time there is plenty of opcode space for a NOP and they do not take many gates
> to support.

On Tuesday, December 6, 2022 at 6:41:43 PM UTC-6, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
>
> >These places come out of the ASM in 64-bit constant form, and the linker
> >can shrink them if the constant fits in a smaller footprint.
> >>
> >>
> >> More debatable though is whether to have a dedicated NOP instruction, or
> >> merely define some other special case (such as "OR R0, R0, R0" as the NOP).
> >>
> >Every ISA has some way to "doing no work" while executing instructions;
<
> ARM64 has WFI and WFE, Intel/AMD have PAUSE and MWAIT. They have the
> benefit of signaling the core that it can enter a lower-power state.
<
In order pipelines can do this on any cache or TLB miss.
<
> >But the question is whether there should be an explicit OpCode for NoOp
> >(or more than one) is a lot different that whether it is possible to do noting
> >by executing an instruction.
> >> ...
> Both of the above have explicit NOP instructions; which on intel are often
> generated by compilers to align code to specific address constraints.
>
> ARM64 has a range of "HINT" instructions; if a hint isn't supported
> by an implementation it becomes a NOP.