On 4/21/2024 8:16 PM, John Savard wrote:
> On Sun, 21 Apr 2024 18:57:27 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:
>> BGB wrote:
>
>>> Like, in-order superscalar isn't going to do crap if nearly every
>>> instruction depends on every preceding instruction. Even pipelining
>>> can't help much with this.
>
>> Pipelining CREATED this (back to back dependencies). No amount of
>> pipelining can eradicate RAW data dependencies.
>
> This is quite true. However, in case an unsophisticated individual
> might read this thread, I think that I shall clarify.
>
> Without pipelining, it is not a problem if each instruction depends on
> the one immediately previous, and so people got used to writing
> programs that way, as it was simple to write the code to do one thing
> before starting to write the code to begin doing another thing.
>

Yeah.

This is also typical of naive compiler output, say:
y=m*x+b;
Turns into RPN as, say:
LD(m) LD(x) MUL LD(b) ADD ST(C)
Which, in a naive compiler (though, one with register allocation) may
become, say:
MULS R8, R9, R12
ADD R12, R10, R13
MOV R13, R11 //MUL output first goes into temporary

But, if MUL is 3c and ADD is 2c, this ends up needing 6 cycles.

The situation would be significantly worse in a compiler lacking
register allocation (would add 8 memory operations to this; similar to
what one gets with "gcc -O0").

For the most part, as can be noted, I was comparing against "gcc -O3" on
the RV64 size, with "-ffuction-sections" and "-Wl,-gc-sections" and
similar, as otherwise GCC's output is significantly larger. Though,
nevermind the seemingly fairly bulky ELF metadata (PE/COFF is seemingly
a bit more compact here). Can note that "-O3" vs "-Os" also doesn't seem
to make that big of a difference for RV64.

If one has another expression, one can shuffle the operations between
the expressions together, and the latency is lower than had no shuffling
occurred; and if one can reduce dependencies enough, operations can be
run in parallel for further gain. But, all this depends on first being
able to shuffle things to break up the register-register dependencies
between instructions.

In BGBCC, this part was done via the WEXifier, which imposes a lot of
annoying restrictions (partly because it starts working after code
generation has already taken place).

In size-optimized code, this doesn't happen, which results in a
performance hit. This is partly since the WEXifier can only work with
32-bit instructions, can't cross labels or relocs, and requires the
register allocator to essentially round-robin the registers to minimize
dependencies, ...

But, preferentially always allocating a new register and avoiding
reusing registers within a basic block, while it reduces dependencies,
also eats a lot more registers (with the indirect cost of increasing the
number that need to be saved/restored, though the size-impact of this is
reduced somewhat via prolog/epilog compression).

Though, one can shuffle stuff at the 3AC level (which exists in my case
between the RPN and final code generation), but this is more hit-or-miss.

Better would have been to go from 3AC to a "virtual assembler", which
could then allow reordering before emitting the actual machine code (and
thus wouldn't be as restricted). This was originally considered, but
ended up not going this way as it seemed like more work (in terms of
internal restructuring) than to shove the logic in after the
machine-code was generated.

But, the current compiler architecture was the result of always doing
the most quick/dirty option at the time, which doesn't necessarily
result in an optimal design.

Granted, OTOH, "waterfall method" doesn't really have the best
track-record either (vs the "hack something together, hack on it some
more, ..." method).

> This remained true when the simplest original form of pipelining was
> brought in - where fetching one instruction from memory was overlapped
> with decoding the previous instruction, and executing the instruction
> before that.
>
> It's only when what was originally called "superpipelining" came
> along, where the execute stages of multiple successive instructions
> could be overlapped, that it was necessary to do something about
> dependencies in order to take advantage of the speedup that could
> provide.
>

Yeah.

Pipeline:
PF:
PC arrives at I$
Selected from:
If Branch: Branch-PC
Else, if Branch-Predicted, Branch Pred Result
Else, LastPC+PCStep
IF:
Fetches 96 bits at PC
Figures how much to advance PC;
Figures out if we can do superscalar here.
Check for register clashes;
Check for valid prefix and suffix;
If both checks pass, go for it.
ID:
Unpack instruction words;
Pipeline now splits into 3 lanes;
Branch predictor does its thing.
ID2/RF:
Results come in from the registers;
Figure out if current bundle can enter EX stages;
Figure out if each predicated instruction should execute.
EX1(EX1C|EX1B|EX1A):
Do stuff: ALU, Initiate memory access, ...
EX2(EX2C|EX2B|EX2A):
Do stuff | results arrive.
EX3(EX3C|EX3B|EX3A):
Results arrive;
Produce any final results.
WB:
Results are written into register file.

By EX1, it is known whether or not the branch will actually be taken, so
(if needed) it may override the former guess of the branch-predictor. By
EX2, the branch-initiation takes effect, and by EX3, the new PC reaches
the I$ (overriding whether else would have normally arrived).

In a few cases (such as a jump between ISA modes), extra cycles may be
needed to make sure everything is caught up (so, the same PC address is
held on the I$ input for around 3 cycles in this case).

This may happen if, say:
Jumping between Baseline, XG2, or RISC-V;
WEXMD changing whether WEX decoding is enabled or disabled;
If disabled, it behaves as if the WEX'ed instructions were scalar;
Jumbo prefixes ignore this (always behaving as-if it were enabled);
...
Mostly to make sure that IF and ID can decode the instructions as is
correct for the mode in question.

> John Savard

MitchAlsup1 wrote:
> BGB wrote:
>
>> On 4/20/2024 5:03 PM, MitchAlsup1 wrote:
>> Like, in-order superscalar isn't going to do crap if nearly every
>> instruction depends on every preceding instruction. Even pipelining
>> can't help much with this.
>
> Pipelining CREATED this (back to back dependencies). No amount of
> pipelining can eradicate RAW data dependencies.
>
>> The compiler can shuffle the instructions into an order to limit the
>> number of register dependencies and better fit the pipeline. But,
>> then, most of the "hard parts" are already done (so it doesn't take
>> much more for the compiler to flag which instructions can run in
>> parallel).
>
> Compiler scheduling works for exactly 1 pipeline implementation and
> is suboptimal for all others.

Well, yeah.

OTOH, if your (definitely not my!) compiler can schedule a 4-wide static
ordering of operations, then it will be very nearly optimal on 2-wide
and 3-wide as well. (The difference is typically in a bit more loop
setup and cleanup code than needed.)

Hand-optimizing Pentium asm code did teach me to "think like a cpu",
which is probably the only part of the experience which is still kind of
relevant. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 4/22/2024 12:49 AM, Terje Mathisen wrote:
> MitchAlsup1 wrote:
>> BGB wrote:
>>
>>> On 4/20/2024 5:03 PM, MitchAlsup1 wrote:
>>> Like, in-order superscalar isn't going to do crap if nearly every
>>> instruction depends on every preceding instruction. Even pipelining
>>> can't help much with this.
>>
>> Pipelining CREATED this (back to back dependencies). No amount of
>> pipelining can eradicate RAW data dependencies.
>>
>>> The compiler can shuffle the instructions into an order to limit the
>>> number of register dependencies and better fit the pipeline. But,
>>> then, most of the "hard parts" are already done (so it doesn't take
>>> much more for the compiler to flag which instructions can run in
>>> parallel).
>>
>> Compiler scheduling works for exactly 1 pipeline implementation and
>> is suboptimal for all others.
>
> Well, yeah.
>
> OTOH, if your (definitely not my!) compiler can schedule a 4-wide static
> ordering of operations, then it will be very nearly optimal on 2-wide
> and 3-wide as well. (The difference is typically in a bit more loop
> setup and cleanup code than needed.)
>
> Hand-optimizing Pentium asm code did teach me to "think like a cpu",
> which is probably the only part of the experience which is still kind of
> relevant. :-)
>

Mine is hard-pressed to even make effective use of the current pipeline,
so going wider does not make sense at present.

As I had noted before, the main merit of 3 wide in my case is that it
makes it easier to justify a 6R register file, which, unlike the 4R
register file, doesn't choke up with trying to run other instructions in
parallel with memory store and similar (which is actually a fairly
serious restriction given how much memory operations tend to clog up
Lane 1; opportunities for "ALU|ST" being more common than "ALU|ALU").

Granted, one could argue that (Reg, Disp) memory addressing could be
supported entirely within a 2R1W pattern, which while true in premise,
does not match my implementation (which always uses indexed addressing
internally, treating the Disp as a virtual register; thus eating 3
register ports).

Well, and for the 4R2W configuration, the main priority is minimizing
LUT cost (which favors leaving it as-is, with the current restrictions).

Granted, some similar issues apply to 128-bit MOV.X and SIMD ops, which
as-is can only exist as scalar ops. These could potentially also be
hacked around (say, to allow ALU|SIMD or ALU|MOV.X, but the "fix" would
cost a lot of LUTs). Mostly in that variability in terms of input
routing does not come cheap.

Though, that said, the 3rd lane still gets used for a share of basic ALU
instructions, so isn't entirely going to waste either.

> Terje
>

On 4/21/2024 6:31 PM, MitchAlsup1 wrote:
> BGB wrote:
>
>> On 4/21/2024 1:57 PM, MitchAlsup1 wrote:
>>> BGB wrote:
>>>
>>> One of the things that I notice with My 66000 is when you get all the
>>> constants you ever need at the calculation OpCodes, you end up with
>>> FEWER instructions that "go random places" such as instructions that
>>> <well> paste constants together. This leave you with a data dependent
>>> string of calculations with occasional memory references. That is::
>>> universal constants gets rid of the easy to pipeline extra instructions
>>> leaving the meat of the algorithm exposed.
>>>
>
>> Possibly true.
>
>> RISC-V tends to have a lot of extra instructions due to lack of big
>> constants and lack of indexed addressing.
>
> You forgot the "every one an his brother" design of the ISA>
>
>> And, BJX2 has a lot of frivolous register-register MOV instructions.
>
> I empower you to get rid of them....

OK, I more meant that the compiler is prone to emit lots of:
MOV Reg, Reg

Rather than, say, the ISA listing being full of redundant "MOV Reg, Reg"
encodings...

But, getting rid of them has been an ongoing battle of compiler fiddling.

Many were popping up from odd corners, say:
Register allocation issues (mostly involving function call/return);
Type casts and promotions between equivalent representations (*1);
...

*1: Had eliminated some of these, by allowing temporaries to be coerced
directly into different types in some cases. But, "for reasons" doesn't
really work with some other types of variables. But, say, int->long, or
casting between pointer types, etc, can be done without needing to do
anything to the value in the register.

But, yes, performance and code density would be better with fewer
frivolous register MOVs.

> <snip>
>>>>> If you design around the notion of a 3R1W register file, FMAC and
>>>>> INSERT
>>>>> fall out of the encoding easily. Done right, one can switch it into
>>>>> a 4R
>>>>> or 4W register file for ENTER and EXIT--lessening the overhead of
>>>>> call/ret.
>>>>>
>>>
>>>> Possibly.
>>>
>>>> It looks like some savings could be possible in terms of prologs and
>>>> epilogs.
>>>
>>>> As-is, these are generally like:
>>>>    MOV    LR, R18
>>>>    MOV    GBR, R19
>>>>    ADD    -192, SP
>>>>    MOV.X  R18, (SP, 176)  //save GBR and LR
>>>>    MOV.X  ...  //save registers
>>>
>>> Why not an instruction that saves LR and GBR without wasting
>>> instructions
>>> to place them side by side prior to saving them ??
>>>
>
>> I have an optional MOV.C instruction, but would need to restructure
>> the code for generating the prologs to make use of them in this case.
>
>> Say:
>>    MOV.C  GBR, (SP, 184)
>>    MOV.C  LR, (SP, 176)
>
>> Though, MOV.C is considered optional.
>
>> There is a "MOV.C Lite" option, which saves some cost by only allowing
>> it for certain CR's (mostly LR and GBR), which also sort of overlaps
>> with (and is needed) by RISC-V mode, because these registers are in
>> GPR land for RV.
>
>> But, in any case, current compiler output shuffles them to R18 and R19
>> before saving them.
>
>
>>>>    WEXMD  2  //specify that we want 3-wide execution here
>>>
>>>>    //Reload GBR, *1
>>>>    MOV.Q  (GBR, 0), R18
>>>>    MOV    0, R0  //special reloc here
>>>>    MOV.Q  (GBR, R0), R18
>>>>    MOV    R18, GBR
>>>
>
>> Correction:
>>  >>    MOV.Q  (R18, R0), R18
>
>
>>> It is gorp like that that lead me to do it in HW with ENTER and EXIT.
>>> Save registers to the stack, setup FP if desired, allocate stack on
>>> SP, and decide if EXIT also does RET or just reloads the file. This
>>> would require 2 free registers if done in pure SW, along with several
>>> MOVs...
>>>
>
>> Possibly.
>> The partial reason it loads into R0 and uses R0 as an index, was that
>> I defined this mechanism before jumbo prefixes existed, and hadn't
>> updated it to allow for jumbo prefixes.
>
> No time like the present...
>

OK. Made this change.

Only a minor change to my compiler and PE loader.

>> Well, and if I used a direct displacement for GBR (which, along with
>> PC, is always BYTE Scale), this would have created a hard limit of 64
>> DLL's per process-space (I defined it as Disp24, which allows a more
>> reasonable hard upper limit of 2M DLLs per process-space).
>
> In my case, restricting myself to 32-bit IP relative addressing, GOT can
> be anywhere within ±2GB of the accessing instruction and can be as big
> as one desires.
>

In this case:
GBR points to the start of ".data" for a given PE image;
This starts with a pointer to a table of GBR pointers for every DLL in
the process;
Each DLL is assigned an index into this table, fixed up at load time;
The magic ritual, when perfored, will get GBR pointing at the
".data"/".bss" sections for that particular DLL.

But, say, one loads the EXE and DLLs.

One creates a program instance by allocating memory for each of the
data/bss sections, copying the data section from the base image, and
putting it in the table. Then jumping to the entry point with the EXE's
section in GBR.

One can fire up a new instance by allocating a new set of data areas,
jumping to the entry point as before. This instance does not need to
know or care that the prior instance exists, even if both exist in the
same address space, and have all their code at the same addresses (since
the ".text" sections are shared between all instances).

Normal PC-relative GOT's can't do this. You would either need multiple
address spaces, or multiple loaded copies of each image.

>> Granted, nowhere near even the limit of 64 as of yet. But, I had noted
>> that Windows programs would often easily exceed this limit, with even
>> a fairly simple program pulling in a fairly large number of random
>> DLLs, so in any case, a larger limit was needed.
>
> Due to the way linkages work in My 66000, each DLL gets its own GOT.
> So there is essentially no bounds on how many can be present/in-use.
> A LD of a GOT[entry] gets a pointer to the external variable.
> A CALX of GOT[entry] is a call through the GOT table using std ABI.
> {{There is no PLT}}
>

OK.

Had done it a little different:
Imported function gets a stub, generally like:
Foo:
MOV.Q (PC, 4), R1
JMP R1
_imp_Foo: .QWORD 0

Import table (or IAT / Import Address Table) points at _imp_Foo and
fixes it up to point at the imported function.

Had defined an alternate version:
Foo:
_imp_Foo:
BRA Abs48

The loader would see and special-case the BRA Abs48 instruction.

But, this latter form ran into a problem:
Things will violently explode if the EXE and DLL (or one DLL and
another) are not in the same ISA mode (say, Baseline vs XG2).

Which means, I am back to the less efficient option of needing to load
then branch.

Granted:
MOV Imm64, R1
JMP R1
Could also work, and saves a few clock cycles.

Doesn't currently extend to global variables, but I don't really feel
this is a huge loss. Might fix eventually.

Generally, loader is hard-coded to assume import by name, as I didn't
feel it worth the bother to try to deal with importing by 16-bit ordinal
number.

>> One potential optimization here is that the main EXE will always be 0
>> in the process, so this sequence could be reduced to, potentially:
>>    MOV.Q (GBR, 0), R18
>>    MOV.C (R18, 0), GBR
>
>> Early on, I did not have the constraint that main EXE was always 0,
>> and had initially assumed it would be treated equivalently to a DLL.
>
>
>>>>    //Generate Stack Canary, *2
>>>>    MOV    0x5149, R18  //magic number (randomly generated)
>>>>    VSKG   R18, R18  //Magic (combines input with SP and magic numbers)
>>>>    MOV.Q  R18, (SP, 144)
>>>
>>>>    ...
>>>>    function-specific stuff
>>>>    ...
>>>
>>>>    MOV    0x5149, R18
>>>>    MOV.Q  (SP, 144), R19
>>>>    VSKC   R18, R19  //Validate canary
>>>>    ...
>>>
>>>
>>>> *1: This part ties into the ABI, and mostly exists so that each PE
>>>> image can get GBR reloaded back to its own ".data"/".bss" sections
>>>> (with
>>>
>>> Universal displacements make GBR unnecessary as a memory reference can
>>> be accompanied with a 16-bit, 32-bit, or 64-bit displacement. Yes,
>>> you can read GOT[#i] directly without a pointer to it.
>>>
>
>> If I were doing a more conventional ABI, I would likely use (PC,
>> Disp33s) for accessing global variables.
>
> Even those 128GB away ??
>

On Sat, 20 Apr 2024 17:07:11 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
>John Savard wrote:

>> And, hey, I'm not the first guy to get sunk because of forgetting what
>> lies under the tip of the iceberg that's above the water.
>
>> That also happened to the captain of the _Titanic_.
>
>Concer-tina-tanic !?!

Oh, dear. This discussion has inspired me to rework the basic design
of Concertina II _yet again_!

The new design, not yet online, will have the following features:

The code stream will continue to be divided into 256-bit blocks.

However, block headers wil be eliminated. Instead, this functionality
will be subsumed into the instruction set.

Case I:

Indicating that from 1 to 7 32-bit instruction slots in a block are
not used for instructions, but instead may contain pseudo-immediates
will be achieved by:

Placing a two-address register-to-register operate instruction in the
first instruction slot in a block. These instructions will have a
three-bit field which, if nonzero, indicates the amount of space
reserved.

To avoid waste, when such an instruction is present in any slot other
than the first, that field will have the following function:

If nonzero, it points to an instruction slot (slots 1 through 7, in
the second through eighth positions) and a duplicate copy of the
instruction in that slot will be placed in the instruction stream
immediately following the instruction with that field.

The following special conditions apply:

If the instruction slot contains a pair of 16-bit instructions, only
the first of those instructions is so inserted for execution.

The instruction slot may not be one that is reserved for
pseudo-immediates, except that it may be the _first_ such slot, in
which case, the first 16 bits of that slot are taken as a 16-bit
instruction, with the format indicated by the first bit (as opposed to
the usual 17th bit) of that instruction slot's contents.

So it's possible to reserve an odd multiple of 16 bits for
pseudo-immediates, so as to avoid waste.

Case II:

Instructions longer than 32 bits are specified by being of the form:

The first instruction slot:

11111
00
(3 bits) length in instruction slots, from 2 to 7
(22 bits) rest of the first part of the instruction

All remaining instruction slots:

11111
(3 bits) position within instruction, from 2 to 7
(24 bits) rest of this part of the instruction

This mechanism, however, will _also_ be used for VLIW functionality or
prefix functionality which was formerly in block headers.

In that case, the first instruction slot, and the remaining
instruction slots, no longer need to be contiguous; instead, ordinary
32-bit instructions or pairs of 16-bit instlructions can occur between
the portions of the ensemble of prefixed instructions formed by this
means.

And there is a third improvement.

When Case I above is in effect, the block in which space for
pseudo-immediates is reserved will be stored in an internal register
in the processor.

Subsequent blocks can contain operate instructions with
pseudo-immediate operands even if no space for pseudo-immediates is
reserved in those blocks. In that case, the retained copy of the last
block encountered in which pseudo-immediates were reserved shall be
referenced instead.

I think these changes will improve code density... or, at least, they
will make it appear that no space is obviously forced to be wasted,
even if no real improvement in code density results.

John Savard

On Mon, 22 Apr 2024 14:13:41 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>On Sat, 20 Apr 2024 17:07:11 +0000, mitchalsup@aol.com (MitchAlsup1)
>wrote:
>>John Savard wrote:
>
>>> And, hey, I'm not the first guy to get sunk because of forgetting what
>>> lies under the tip of the iceberg that's above the water.
>>
>>> That also happened to the captain of the _Titanic_.
>>
>>Concer-tina-tanic !?!
>
>Oh, dear. This discussion has inspired me to rework the basic design
>of Concertina II _yet again_!
>
>The new design, not yet online, will have the following features:
>
>The code stream will continue to be divided into 256-bit blocks.
>
>However, block headers wil be eliminated. Instead, this functionality
>will be subsumed into the instruction set.
>
>Case I:
>
>Indicating that from 1 to 7 32-bit instruction slots in a block are
>not used for instructions, but instead may contain pseudo-immediates
>will be achieved by:
>
>Placing a two-address register-to-register operate instruction in the
>first instruction slot in a block. These instructions will have a
>three-bit field which, if nonzero, indicates the amount of space
>reserved.
>
>To avoid waste, when such an instruction is present in any slot other
>than the first, that field will have the following function:
>
>If nonzero, it points to an instruction slot (slots 1 through 7, in
>the second through eighth positions) and a duplicate copy of the
>instruction in that slot will be placed in the instruction stream
>immediately following the instruction with that field.
>
>The following special conditions apply:
>
>If the instruction slot contains a pair of 16-bit instructions, only
>the first of those instructions is so inserted for execution.
>
>The instruction slot may not be one that is reserved for
>pseudo-immediates, except that it may be the _first_ such slot, in
>which case, the first 16 bits of that slot are taken as a 16-bit
>instruction, with the format indicated by the first bit (as opposed to
>the usual 17th bit) of that instruction slot's contents.
>
>So it's possible to reserve an odd multiple of 16 bits for
>pseudo-immediates, so as to avoid waste.
>
>Case II:
>
>Instructions longer than 32 bits are specified by being of the form:
>
>The first instruction slot:
>
>11111
>00
>(3 bits) length in instruction slots, from 2 to 7
>(22 bits) rest of the first part of the instruction
>
>All remaining instruction slots:
>
>11111
>(3 bits) position within instruction, from 2 to 7
>(24 bits) rest of this part of the instruction
>
>This mechanism, however, will _also_ be used for VLIW functionality or
>prefix functionality which was formerly in block headers.
>
>In that case, the first instruction slot, and the remaining
>instruction slots, no longer need to be contiguous; instead, ordinary
>32-bit instructions or pairs of 16-bit instlructions can occur between
>the portions of the ensemble of prefixed instructions formed by this
>means.
>
>And there is a third improvement.
>
>When Case I above is in effect, the block in which space for
>pseudo-immediates is reserved will be stored in an internal register
>in the processor.
>
>Subsequent blocks can contain operate instructions with
>pseudo-immediate operands even if no space for pseudo-immediates is
>reserved in those blocks. In that case, the retained copy of the last
>block encountered in which pseudo-immediates were reserved shall be
>referenced instead.
>
>I think these changes will improve code density... or, at least, they
>will make it appear that no space is obviously forced to be wasted,
>even if no real improvement in code density results.

The page has now been updated to reflect this modified design.

John Savard

On Mon, 22 Apr 2024 16:22:11 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>On Mon, 22 Apr 2024 14:13:41 -0600, John Savard
><quadibloc@servername.invalid> wrote:

>>The first instruction slot:
>>
>>11111
>>00
>>(3 bits) length in instruction slots, from 2 to 7
>>(22 bits) rest of the first part of the instruction
>>
>>All remaining instruction slots:
>>
>>11111
>>(3 bits) position within instruction, from 2 to 7
>>(24 bits) rest of this part of the instruction

>The page has now been updated to reflect this modified design.

And I thought I was on to something.

The functionality - pseudo-immediates and VLIW features - was all the
same, but now everything was so much simpler. The only thing that
needed to be in a header, the three-bit field that reserved space for
pseudo-immediates, now had just three bits of overhead.

Everything else followed a normal instruction model, instead of a
complicated header.

But... if I use a header with 22 bits usable to turn instruction words
that have 22 bits available...

into instructions that are _longer_ than 32 bits...

well, guess what?

If I use half the opcode space for four-word instructions, then one
header with 22 bits available can add 7 bits to each of three
subsequent instructions.

However, 24 plus 7 is 31.

So I'm stuck at putting two instructions in three words even for a
modest extension of the instruction set...

never mind adding a whole bunch of bits for stuff like predication!

I can tease out a couple of extra bits, so that I have a 22-bit
starting word, but 26 bits in each following one, by replacing the
three bit "position" field with a field that just contains 0 in every
instruction slot but the last one, indicated with a 1.

With 26 bits, to get 33 bits - all I need for a nice expansion of the
instruction set to its "full" form - I need to add seven bits to each
one, so that now does allow one starting word to prefix three
instructions.

Still not great, but adequate. And the first word doesn't really need
a length field either, it just needs to indicate it's the first one.
Which is how I had worked something like this before.

John Savard

John Savard wrote:

> On Sat, 20 Apr 2024 17:07:11 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:
>>John Savard wrote:

>>> And, hey, I'm not the first guy to get sunk because of forgetting what
>>> lies under the tip of the iceberg that's above the water.
>>
>>> That also happened to the captain of the _Titanic_.
>>
>>Concer-tina-tanic !?!

> Oh, dear. This discussion has inspired me to rework the basic design
> of Concertina II _yet again_!

I suggest it is time for Concertina III.......

> The new design, not yet online, will have the following features:

> The code stream will continue to be divided into 256-bit blocks.

Why not a whole cache line ??

> However, block headers wil be eliminated. Instead, this functionality
> will be subsumed into the instruction set.

> Case I:

> Indicating that from 1 to 7 32-bit instruction slots in a block are
> not used for instructions, but instead may contain pseudo-immediates
> will be achieved by:

> Placing a two-address register-to-register operate instruction in the
> first instruction slot in a block. These instructions will have a
> three-bit field which, if nonzero, indicates the amount of space
> reserved.

> To avoid waste, when such an instruction is present in any slot other
> than the first, that field will have the following function:

> If nonzero, it points to an instruction slot (slots 1 through 7, in
> the second through eighth positions) and a duplicate copy of the
> instruction in that slot will be placed in the instruction stream
> immediately following the instruction with that field.

> The following special conditions apply:

> If the instruction slot contains a pair of 16-bit instructions, only
> the first of those instructions is so inserted for execution.

> The instruction slot may not be one that is reserved for
> pseudo-immediates, except that it may be the _first_ such slot, in
> which case, the first 16 bits of that slot are taken as a 16-bit
> instruction, with the format indicated by the first bit (as opposed to
> the usual 17th bit) of that instruction slot's contents.

> So it's possible to reserve an odd multiple of 16 bits for
> pseudo-immediates, so as to avoid waste.

> Case II:

> Instructions longer than 32 bits are specified by being of the form:

> The first instruction slot:

> 11111
> 00
> (3 bits) length in instruction slots, from 2 to 7
> (22 bits) rest of the first part of the instruction

> All remaining instruction slots:

> 11111
> (3 bits) position within instruction, from 2 to 7
> (24 bits) rest of this part of the instruction

> This mechanism, however, will _also_ be used for VLIW functionality or
> prefix functionality which was formerly in block headers.

> In that case, the first instruction slot, and the remaining
> instruction slots, no longer need to be contiguous; instead, ordinary
> 32-bit instructions or pairs of 16-bit instlructions can occur between
> the portions of the ensemble of prefixed instructions formed by this
> means.

> And there is a third improvement.

> When Case I above is in effect, the block in which space for
> pseudo-immediates is reserved will be stored in an internal register
> in the processor.

> Subsequent blocks can contain operate instructions with
> pseudo-immediate operands even if no space for pseudo-immediates is
> reserved in those blocks. In that case, the retained copy of the last
> block encountered in which pseudo-immediates were reserved shall be
> referenced instead.

> I think these changes will improve code density... or, at least, they
> will make it appear that no space is obviously forced to be wasted,
> even if no real improvement in code density results.

> John Savard

On Tue, 23 Apr 2024 01:53:26 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>I suggest it is time for Concertina III.......

If the old Concertina II were worth keeping...

>Why not a whole cache line ??

That would be one way to allow the overhead of a block prefix to be
minimized.

But that starts to look like just having mode bits for an entire
program.

John Savard

On Mon, 22 Apr 2024 19:36:54 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>I can tease out a couple of extra bits, so that I have a 22-bit
>starting word, but 26 bits in each following one, by replacing the
>three bit "position" field with a field that just contains 0 in every
>instruction slot but the last one, indicated with a 1.
>
>With 26 bits, to get 33 bits - all I need for a nice expansion of the
>instruction set to its "full" form - I need to add seven bits to each
>one, so that now does allow one starting word to prefix three
>instructions.
>
>Still not great, but adequate. And the first word doesn't really need
>a length field either, it just needs to indicate it's the first one.
>Which is how I had worked something like this before.

But fully half the opcode space is allocated to 16-bit instructions.
EVen though that half doesn't really play nice with other things, it's
too tempting a target to ignore. But the price would be losing the
fully parallel nature of decoding.

John Savard

On Sun, 21 Apr 2024 00:43:21 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>Address arithmetic is ADD only and does not care about signs or
>overflow. There is no concept of a negative base register or a
>negative index register (or, for that matter, a negative displace-
>ment), overflow, underflow, carry, ...

Stack frame pointers often point to the middle of the frame and need
to access data using both positive and negative displacements.

Some GC schemes use negative displacements to access object headers.

On Mon, 22 Apr 2024 20:22:12 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>But fully half the opcode space is allocated to 16-bit instructions.
>EVen though that half doesn't really play nice with other things, it's
>too tempting a target to ignore. But the price would be losing the
>fully parallel nature of decoding.

After heading out to buy groceries, my head cleared enough to discard
the various complicated and bizarre schemes I was considering to deal
with the issue, and instead to drastically reduce the overhead for the
instructions longer than 32 bits, now that this had become a major
concern due to also usiing this format for prefixed instructions as
well, in a simple and straightforward manner.

John Savard

George Neuner wrote:

> On Sun, 21 Apr 2024 00:43:21 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:

>>Address arithmetic is ADD only and does not care about signs or
>>overflow. There is no concept of a negative base register or a
>>negative index register (or, for that matter, a negative displace-
>>ment), overflow, underflow, carry, ...

> Stack frame pointers often point to the middle of the frame and need
> to access data using both positive and negative displacements.

Yes, one accesses callee saved registers with positive displacements
and local variables with negative accesses. One simply needs to know
where the former stops and the later begins. ENTER and EXIT know this
by the register count and by the stack allocation size.

> Some GC schemes use negative displacements to access object headers.

Those are negative displacements not negative bases or indexes.

On 4/23/2024 1:54 AM, John Savard wrote:
> On Mon, 22 Apr 2024 20:22:12 -0600, John Savard
> <quadibloc@servername.invalid> wrote:
>
>> But fully half the opcode space is allocated to 16-bit instructions.
>> EVen though that half doesn't really play nice with other things, it's
>> too tempting a target to ignore. But the price would be losing the
>> fully parallel nature of decoding.
>
> After heading out to buy groceries, my head cleared enough to discard
> the various complicated and bizarre schemes I was considering to deal
> with the issue, and instead to drastically reduce the overhead for the
> instructions longer than 32 bits, now that this had become a major
> concern due to also usiing this format for prefixed instructions as
> well, in a simple and straightforward manner.
>

You know, one could just be like, say:
xxxx-xxxx-xxxx-xxx0 //16-bit op
xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-xx01 //32-bit op
xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-x011 //32-bit op
xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-0111 //32-bit op
xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-1111 //jumbo prefix (64+)

And call it "good enough"...

Then, say (6b registers):
zzzz-mmmm-nnnn-zzz0 //16-bit op (2R)
zzzz-tttt-ttss-ssss nnnn-nnpp-zzzz-xxx1 //32-bit op (3R)
iiii-iiii-iiss-ssss nnnn-nnpp-zzzz-xxx1 //32-bit op (3RI, Imm10)
iiii-iiii-iiii-iiii nnnn-nnpp-zzzz-xxx1 //32-bit op (2RI, Imm16)
iiii-iiii-iiii-iiii iiii-iipp-zzzz-xxx1 //32-bit op (Branch)

Or (5b registers):
zzzz-mmmm-nnnn-zzz0 //16-bit op (2R)
zzzz-zttt-ttzs-ssss nnnn-nzpp-zzzz-xxx1 //32-bit op (3R)
iiii-iiii-iiis-ssss nnnn-nzpp-zzzz-xxx1 //32-bit op (3RI, Imm11)
iiii-iiii-iiii-iiii nnnn-nzpp-zzzz-xxx1 //32-bit op (2RI, Imm16)
iiii-iiii-iiii-iiii iiii-iipp-zzzz-xxx1 //32-bit op (Branch)

....

> John Savard

BGB wrote:

> On 4/23/2024 1:54 AM, John Savard wrote:
>> On Mon, 22 Apr 2024 20:22:12 -0600, John Savard
>> <quadibloc@servername.invalid> wrote:
>>
>>> But fully half the opcode space is allocated to 16-bit instructions.
>>> EVen though that half doesn't really play nice with other things, it's
>>> too tempting a target to ignore. But the price would be losing the
>>> fully parallel nature of decoding.
>>
>> After heading out to buy groceries, my head cleared enough to discard
>> the various complicated and bizarre schemes I was considering to deal
>> with the issue, and instead to drastically reduce the overhead for the
>> instructions longer than 32 bits, now that this had become a major
>> concern due to also usiing this format for prefixed instructions as
>> well, in a simple and straightforward manner.
>>

> You know, one could just be like, say:
> xxxx-xxxx-xxxx-xxx0 //16-bit op
> xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-xx01 //32-bit op
> xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-x011 //32-bit op
> xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-0111 //32-bit op
> xxxx-xxxx-xxxx-xxxx xxxx-xxxx-xxxx-1111 //jumbo prefix (64+)

> And call it "good enough"...

> Then, say (6b registers):
> zzzz-mmmm-nnnn-zzz0 //16-bit op (2R)
> zzzz-tttt-ttss-ssss nnnn-nnpp-zzzz-xxx1 //32-bit op (3R)
> iiii-iiii-iiss-ssss nnnn-nnpp-zzzz-xxx1 //32-bit op (3RI, Imm10)
> iiii-iiii-iiii-iiii nnnn-nnpp-zzzz-xxx1 //32-bit op (2RI, Imm16)
> iiii-iiii-iiii-iiii iiii-iipp-zzzz-xxx1 //32-bit op (Branch)

> Or (5b registers):
> zzzz-mmmm-nnnn-zzz0 //16-bit op (2R)
> zzzz-zttt-ttzs-ssss nnnn-nzpp-zzzz-xxx1 //32-bit op (3R)
> iiii-iiii-iiis-ssss nnnn-nzpp-zzzz-xxx1 //32-bit op (3RI, Imm11)
> iiii-iiii-iiii-iiii nnnn-nzpp-zzzz-xxx1 //32-bit op (2RI, Imm16)
> iiii-iiii-iiii-iiii iiii-iipp-zzzz-xxx1 //32-bit op (Branch)

> ....

Punt on the 16-bit instructions::

000110 CONDI rrrrr PRED xxthen xxelse
000111 ddddd rrrrr SHF rwidth roffst
001001 ddddd rrrrr DscLd MemOp rrrrr
001010 ddddd rrrrr I12Sd 2-OPR rrrrr
001100 ddddd rrrrr I12 3OP rrrrr rrrrr
001101 ddddd rrrrr I12Sd 1-OPERA TIONx
01100 bitnum rrrrr 16-bit-displacement
011010 CONDI rrrrr 16-bit-displacement
011110 26-bit-displacementtttttttttttt
011111 26-bit-displacementtttttttttttt
100000
to
101110 ddddd rrrrr 16-bit-displacement
110000
to
111100 ddddd rrrrr 16-bit-immediateeee

>> John Savard

On Sat, 20 Apr 2024 18:06:22 -0600, John Savard wrote:

> Since there was only one set of arithmetic instrucions, that meant that
> when you wrote code to operate on unsigned values, you had to remember
> that the normal names of the condition code values were oriented around
> signed arithmetic.

I thought architectures typically had separate condition codes for “carry”
versus “overflow”. That way, you didn’t need signed versus unsigned
versions of add, subtract and compare; it was just a matter of looking at
the right condition codes on the result.

Lawrence D'Oliveiro wrote:

> On Sat, 20 Apr 2024 18:06:22 -0600, John Savard wrote:

>> Since there was only one set of arithmetic instrucions, that meant that
>> when you wrote code to operate on unsigned values, you had to remember
>> that the normal names of the condition code values were oriented around
>> signed arithmetic.

> I thought architectures typically had separate condition codes for “carry”
> versus “overflow”. That way, you didn’t need signed versus unsigned
> versions of add, subtract and compare; it was just a matter of looking at
> the right condition codes on the result.

Maybe now with 4-or-5-bit condition codes yes,
But the early machines (360) with 2-bit codes were already constricted.

On Thu, 25 Apr 2024 02:50:09 +0000, MitchAlsup1 wrote:

> Lawrence D'Oliveiro wrote:
>
>> On Sat, 20 Apr 2024 18:06:22 -0600, John Savard wrote:
>
>>> Since there was only one set of arithmetic instrucions, that meant
>>> that when you wrote code to operate on unsigned values, you had to
>>> remember that the normal names of the condition code values were
>>> oriented around signed arithmetic.
>
>> I thought architectures typically had separate condition codes for
>> “carry” versus “overflow”. That way, you didn’t need signed versus
>> unsigned versions of add, subtract and compare; it was just a matter of
>> looking at the right condition codes on the result.
>
> Maybe now with 4-or-5-bit condition codes yes,
> But the early machines (360) with 2-bit codes were already constricted.

The DEC PDP-6, from around 1964, same time as the System/360, had separate
carry and overflow flags.

On Thu, 25 Apr 2024 01:00:21 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
>On Sat, 20 Apr 2024 18:06:22 -0600, John Savard wrote:
>
>> Since there was only one set of arithmetic instrucions, that meant that
>> when you wrote code to operate on unsigned values, you had to remember
>> that the normal names of the condition code values were oriented around
>> signed arithmetic.
>
>I thought architectures typically had separate condition codes for “carry”
>versus “overflow”. That way, you didn’t need signed versus unsigned
>versions of add, subtract and compare; it was just a matter of looking at
>the right condition codes on the result.

Yes; I thought that was the same as what I just said.

John Savard

On Tue, 23 Apr 2024 17:58:41 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>George Neuner wrote:
>
>> On Sun, 21 Apr 2024 00:43:21 +0000, mitchalsup@aol.com (MitchAlsup1)
>> wrote:
>
>>>Address arithmetic is ADD only and does not care about signs or
>>>overflow. There is no concept of a negative base register or a
>>>negative index register (or, for that matter, a negative displace-
>>>ment), overflow, underflow, carry, ...
>
>> Stack frame pointers often point to the middle of the frame and need
>> to access data using both positive and negative displacements.
>
>Yes, one accesses callee saved registers with positive displacements
>and local variables with negative accesses. One simply needs to know
>where the former stops and the later begins. ENTER and EXIT know this
>by the register count and by the stack allocation size.
>
>> Some GC schemes use negative displacements to access object headers.
>
>Those are negative displacements not negative bases or indexes.

I was reacting to your message (quoted fully above) which,
paraphrased, says "address arithmetic is add only and there is no
concept of a negative displacement".

In one sense you are correct: the result of the calculation has to be
considered as unsigned in the range 0..max_memory ... ie. there is no
concept of negative *address*.

However, the components being added to form the address, I believe are
a different matter.

I agree that negative base is meaningless.

However, negative index and negative displacement both do have
meaning. The inclusion of specialized index registers is debatable
[I'm in the GPR camp], but I do believe that index and displacement
*values* both always should be considered as signed.

YMMV.

On 4/25/2024 4:01 PM, George Neuner wrote:
> On Tue, 23 Apr 2024 17:58:41 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:
>
>> George Neuner wrote:
>>
>>> On Sun, 21 Apr 2024 00:43:21 +0000, mitchalsup@aol.com (MitchAlsup1)
>>> wrote:
>>
>>>> Address arithmetic is ADD only and does not care about signs or
>>>> overflow. There is no concept of a negative base register or a
>>>> negative index register (or, for that matter, a negative displace-
>>>> ment), overflow, underflow, carry, ...
>>
>>> Stack frame pointers often point to the middle of the frame and need
>>> to access data using both positive and negative displacements.
>>
>> Yes, one accesses callee saved registers with positive displacements
>> and local variables with negative accesses. One simply needs to know
>> where the former stops and the later begins. ENTER and EXIT know this
>> by the register count and by the stack allocation size.
>>
>>> Some GC schemes use negative displacements to access object headers.
>>
>> Those are negative displacements not negative bases or indexes.
>
> I was reacting to your message (quoted fully above) which,
> paraphrased, says "address arithmetic is add only and there is no
> concept of a negative displacement".
>
> In one sense you are correct: the result of the calculation has to be
> considered as unsigned in the range 0..max_memory ... ie. there is no
> concept of negative *address*.
>
> However, the components being added to form the address, I believe are
> a different matter.
>
> I agree that negative base is meaningless.
>
> However, negative index and negative displacement both do have
> meaning. The inclusion of specialized index registers is debatable
> [I'm in the GPR camp], but I do believe that index and displacement
> *values* both always should be considered as signed.
>

Agreed in the sense that negative displacements exist.

However, can note that positive displacements tend to be significantly
more common than negative ones. Whether or not it makes sense to have a
negative displacement, depending mostly on the probability of greater
than half of the missed displacements being negative.

From what I can tell, this seems to be:
~ 10 bits, scaled.
~ 13 bits, unscaled.

So, say, an ISA like RISC-V might have had a slightly hit rate with
unsigned displacements than with signed displacements, but if one added
1 or 2 bits, signed would have still been a clear winner (or, with 1 or
2 fewer bits, unsigned a clear winner).

I ended up going with signed displacements for XG2, but it was pretty
close to break-even in this case (when expanding from the 9-bit unsigned
displacements in Baseline).

Granted, all signed or all-unsigned might be better from an ISA design
consistency POV.

If one had 16-bit displacements, then unscaled displacements would make
sense; otherwise scaled displacements seem like a win (misaligned
displacements being much less common than aligned displacements).

But, admittedly, main reason I went with unscaled for GBR-rel and PC-rel
Load/Store, was because using scaled displacements here would have
required more relocation types (nevermind if the hit rate for unscaled
9-bit displacements is "pretty weak").

Though, did end up later adding specialized Scaled GBR-Rel Load/Store
ops (to improve code density), so it might have been better in
retrospect had I instead just went the "keep it scaled and add more
reloc types to compensate" option.

....

> YMMV.

BGB wrote:

> On 4/25/2024 4:01 PM, George Neuner wrote:
>> On Tue, 23 Apr 2024 17:58:41 +0000, mitchalsup@aol.com (MitchAlsup1)
>> wrote:
>>

> Agreed in the sense that negative displacements exist.

> However, can note that positive displacements tend to be significantly
> more common than negative ones. Whether or not it makes sense to have a
> negative displacement, depending mostly on the probability of greater
> than half of the missed displacements being negative.

> From what I can tell, this seems to be:
> ~ 10 bits, scaled.
> ~ 13 bits, unscaled.

> So, say, an ISA like RISC-V might have had a slightly hit rate with
> unsigned displacements than with signed displacements, but if one added
> 1 or 2 bits, signed would have still been a clear winner (or, with 1 or
> 2 fewer bits, unsigned a clear winner).

> I ended up going with signed displacements for XG2, but it was pretty
> close to break-even in this case (when expanding from the 9-bit unsigned
> displacements in Baseline).

> Granted, all signed or all-unsigned might be better from an ISA design
> consistency POV.

> If one had 16-bit displacements, then unscaled displacements would make
> sense; otherwise scaled displacements seem like a win (misaligned
> displacements being much less common than aligned displacements).

What we need is ~16-bit displacements where 82½%-91¼% are positive.

How does one use a frame pointer without negative displacements ??

[FP+disp] accesses callee save registers
[FP-disp] accesses local stack variables and descriptors

[SP+disp] accesses argument and result values

> But, admittedly, main reason I went with unscaled for GBR-rel and PC-rel
> Load/Store, was because using scaled displacements here would have
> required more relocation types (nevermind if the hit rate for unscaled
> 9-bit displacements is "pretty weak").

> Though, did end up later adding specialized Scaled GBR-Rel Load/Store
> ops (to improve code density), so it might have been better in
> retrospect had I instead just went the "keep it scaled and add more
> reloc types to compensate" option.

> ....

>> YMMV.

mitchalsup@aol.com (MitchAlsup1) writes:
>What we need is ~16-bit displacements where 82½%-91¼% are positive.

What are these funny numbers about?

Do you mean that you want number ranges like -11468..54067 (82.5%
positive) or -5734..59801 (91.25% positive)? Which one of those? And
why not, say -8192..57343 (87.5% positive)?

>How does one use a frame pointer without negative displacements ??

You let it point to the lowest address you want to access. That moves
the problem to unwinding frame pointer chains where the unwinder does
not know the frame-specific difference between the frame pointer and
the pointer of the next frame.

An alternative is to have a frame-independent difference that leaves
enough room that, say 90% (or 99%, or whatever) of the frames don't
need negative offsets from that frame.

Likewise, if you have signed displacements, and are unhappy about the
skewed usage, you can let the frame pointer point at an offset from
the pointer to the next fram such that the usage is less skewed.

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

On 4/26/2024 8:25 AM, MitchAlsup1 wrote:
> BGB wrote:
>
>> On 4/25/2024 4:01 PM, George Neuner wrote:
>>> On Tue, 23 Apr 2024 17:58:41 +0000, mitchalsup@aol.com (MitchAlsup1)
>>> wrote:
>>>
>
>> Agreed in the sense that negative displacements exist.
>
>> However, can note that positive displacements tend to be significantly
>> more common than negative ones. Whether or not it makes sense to have
>> a negative displacement, depending mostly on the probability of
>> greater than half of the missed displacements being negative.
>
>>  From what I can tell, this seems to be:
>>    ~ 10 bits, scaled.
>>    ~ 13 bits, unscaled.
>
>
>> So, say, an ISA like RISC-V might have had a slightly hit rate with
>> unsigned displacements than with signed displacements, but if one
>> added 1 or 2 bits, signed would have still been a clear winner (or,
>> with 1 or 2 fewer bits, unsigned a clear winner).
>
>> I ended up going with signed displacements for XG2, but it was pretty
>> close to break-even in this case (when expanding from the 9-bit
>> unsigned displacements in Baseline).
>
>
>> Granted, all signed or all-unsigned might be better from an ISA design
>> consistency POV.
>
>
>> If one had 16-bit displacements, then unscaled displacements would
>> make sense; otherwise scaled displacements seem like a win (misaligned
>> displacements being much less common than aligned displacements).
>
> What we need is ~16-bit displacements where 82½%-91¼% are positive.
>

I was seeing stats more like 99.8% positive, 0.2% negative.

There was enough of a bias that, below 10 bits, if one takes all the
remaining cases, zero extending would always win, until reaching 10
bits, when the number of missed reaches 50% negative (along with
positive displacements larger than 512).

So, one can make a choice: -512..511, or 0..1023, ...

In XG2, I ended up with -512..511, for pros or cons (for some programs,
this choice is optimal, for others it is not).

Where, when scaled for QWORD, this is +/- 4K.

If one had a 16-bit displacement, it would be a choice between +/- 32K,
or (scaled) +/- 256K, or 0..512K, ...

For the special purpose "LEA.Q (GBR, Disp16), Rn" instruction, I ended
up going unsigned, where for a lot of the programs I am dealing with,
this is big enough to cover ".data" and part of ".bss", generally used
for arrays which need the larger displacements (the compiler lays things
out so that most of the commonly used variables are closer to the start
of ".data", so can use smaller displacements).

Does implicitly require that all non-trivial global arrays have at least
64-bit alignment.

Note that seemingly both BGBCC and GCC have variations on this
optimization, though in GCC's case it requires special command-line
options ("-fdata-sections", etc).

> How does one use a frame pointer without negative displacements ??
>
> [FP+disp] accesses callee save registers
> [FP-disp] accesses local stack variables and descriptors
>
> [SP+disp] accesses argument and result values
>

In my case, all of these are [SP+Disp], granted, there is no frame
pointer and stack frames are fixed-size in BGBCC.

This is typically with a frame layout like:
Argument/Spill space
-- Frame Top
Register Save
(Stack Canary)
Local arrays/structs
Local variables
Argument/Spill Space
-- Frame Bottom

Contrast with traditional x86 layout, which puts saved registers and
local variables near the frame-pointer, which points near the top of the
stack frame.

Though, in a majority of functions, the MOV.L and MOV.Q functions have a
big enough displacement to cover the whole frame (excludes functions
which have a lot of local arrays or similar, though overly large local
arrays are auto-folded to using heap allocation, but at present this
logic is based on the size of individual arrays rather than on the total
combined size of the stack frame).

Adding a frame pointer (with negative displacements) wouldn't make a big
difference in XG2 Mode, but would be more of an issue for (pure)
Baseline, where options are either to load the displacement into a
register, or use a jumbo prefix.

>> But, admittedly, main reason I went with unscaled for GBR-rel and
>> PC-rel Load/Store, was because using scaled displacements here would
>> have required more relocation types (nevermind if the hit rate for
>> unscaled 9-bit displacements is "pretty weak").
>
>> Though, did end up later adding specialized Scaled GBR-Rel Load/Store
>> ops (to improve code density), so it might have been better in
>> retrospect had I instead just went the "keep it scaled and add more
>> reloc types to compensate" option.
>
>
>> ....
>
>
>>> YMMV.

MitchAlsup1 wrote:
> BGB wrote:
>
>> If one had 16-bit displacements, then unscaled displacements would
>> make sense; otherwise scaled displacements seem like a win (misaligned
>> displacements being much less common than aligned displacements).
>
> What we need is ~16-bit displacements where 82½%-91¼% are positive.
>
> How does one use a frame pointer without negative displacements ??
>
> [FP+disp] accesses callee save registers
> [FP-disp] accesses local stack variables and descriptors
>
> [SP+disp] accesses argument and result values

A sign extended 16-bit offsets would cover almost all such access needs
so I really don't see the need for funny business.

But if you really want a skewed range offset it could use something like
excess-256 encoding which zero extends the immediate then subtract 256
(or whatever) from it, to give offsets in the range -256..+65535-256.
So an immediate value of 0 equals an offset of -256.