On Saturday, April 1, 2023 at 1:55:35 PM UTC-5, BGB wrote:
> On 3/31/2023 4:24 PM, robf...@gmail.com wrote:
> > On Friday, March 31, 2023 at 4:16:12 PM UTC-4, John Dallman wrote:
> >> In article <0904a0d8-d657-4176...@googlegroups.com>,
> >> robf...@gmail.com () wrote:
> >>
> >>> And, I would like to get rid of program counter relative addressing
> >>> and use function address offsets. That way all displacements could
> >>> be positive offsets.
> >> Setting a hard upper limit on the size of a function is rather brave. How
> >> would a function that exceeded it be executed?
> >>
> >> John
> >
> > Regarding internal branching also non-PC relative. A 16-bit offset
> > is likely enough to cover the majority of cases.
> >
> > Most functions are 4kB or less. If writing a function over 64kB in length
> > there may be something wrong with the code structure. It could be broken
> > up into smaller functions.
<
That 16-bit flow control displacement covers 256KB of code (not 64KB).
<
> > Otherwise a second pointer register would need to be updated with a
> > reasonable value to branch offset from. I think ugly, but not impossible.
> >
> If the ISA breaks in some fundamental way because someones' "switch()"
> or similar is just a little too big, this isn't ideal...
<
{In gomer Pyle's best voice}
Surprise, surprise, surprise........
>
> Better to just stick with ye olde PC relative branches IMHO.
>
>
> As for displacement, 16-bit would probably be fine.
<
At the 99.8% level, yes; at 6-sigma, no.
>
> In BJX2, I initially started with 16-bit branches, but then later went
> to 20 bit as I wanted to be able to have branches reach across the
> entire ".text" section for a typical program.
<
I have 16-bit conditional branches and 26-bit unconditional branches
and Calls. These suffice (again at the 99.8% level) for single modules
coming out of the linker.
<
But no displacement suffices for dynamic external data or function
linkages.
>
> But, then initially spent dedicated encoding space for BT/BF Disp20,
> which are now deprecated and may be later removed (such that the
> encoding space can be reclaimed). The replacement being to encode "BT/BF
> Disp20" as "BRA?T/F Disp20" (as predicated ops had previously been
> promoted to being part of the core ISA).
>
>
> There are some branch forms with an 8-bit displacement, but these are a
> little weak, as an 8-bit displacement is hit-or-miss even for "if()"
> blocks and "while()" loops.
>
I got 16-bit conditional and 26-bit unconditional branch displacements
and never found the need for more (subject to dynamic external linking.)
>
> I had considered adding a possible "Bcc Rn, Disp12" encoding. This would
<
So you started with 16, then added 20 later to be deprecated, then added 8
and now you are looking for 12. It seems to me that a rethink in the encoding
that would accommodate all flavors more uniformly is in order.
<
> cover most normal loops. But, still debatable vs CMPxx+BT/BF. Would need
> to decide some between spending 6 of the 16 Disp12 spots on the branch
> cases, or merely 3, with predication encoding the other part.
>
> BNE Rn, Disp12 => BEQ?F Rn, Disp12
> BLE Rn, Disp12 => BGT?F Rn, Disp12
> BLT Rn, Disp12 => BGE?F Rn, Disp12
>
> Possibly with these ops only being defined for predicated encodings (the
> unconditional forms encoding "something else").
>
> Or try to find some "odd corner" to stick it into (vs spending encoding
> space in the F8 block).
>
> Say:
> The space occupied by BT?T/BT?F gets reused for these:
> E0dd_Eeod => Bcc?T Ro, Disp12
> E4dd_Eeod => Bcc?F Ro, Disp12
> With the En/Em bits encoding the CC:
> 00 = EQ / NE
> 01 = GT / LE
> 10 = GE / LT
> 11 = ?
> The Eq bit would select between a 32 and 64 bit comparison.
>
> Though, this would preclude being able to later reclaim this space for
> normal 3R ops. However, as-is, these encodings are effectively invalid.
>
> Could also overlap it with BSR, but this leaves an issue for whether
> BSR?T / BSR?F should be left open as a possibility.
>
> ...
>
>
> >

In article <ovHVL.411107$Lfzc.398467@fx36.iad>, scott@slp53.sl.home
(Scott Lurndal) wrote:
> jgd@cix.co.uk (John Dallman) writes:
> >Setting a hard upper limit on the size of a function is rather
> >brave. How would a function that exceeded it be executed?
>
> I can't help but wonder if all this emphasis on instruction set
> efficiency is ultimately misguided. Does it really matter to
> any real-world workload on modern multiple issue out-of-order
> cores, just how wide a branch offset in an instruction word is?

The thing that matters most, once you're building big cores like that, is
often the rate at which you can get code and data in and out of the cores.
So a dense instruction encoding is valuable, simply because it makes the
caches more effective.

Branches to branches risk giving you two cache misses, at the
intermediate and final destinations, so they're worth avoiding. That
makes long-ranged branches worth having. Naturally, they conflict to some
degree with dense encoding.

John

On Saturday, April 1, 2023 at 2:52:52 PM UTC-5, John Dallman wrote:
> In article <ovHVL.411107$Lfzc....@fx36.iad>, sc...@slp53.sl.home
> (Scott Lurndal) wrote:
> > j...@cix.co.uk (John Dallman) writes:
> > >Setting a hard upper limit on the size of a function is rather
> > >brave. How would a function that exceeded it be executed?
> >
> > I can't help but wonder if all this emphasis on instruction set
> > efficiency is ultimately misguided. Does it really matter to
> > any real-world workload on modern multiple issue out-of-order
> > cores, just how wide a branch offset in an instruction word is?
<
> The thing that matters most, once you're building big cores like that, is
> often the rate at which you can get code and data in and out of the cores..
> So a dense instruction encoding is valuable, simply because it makes the
> caches more effective.
>
> Branches to branches risk giving you two cache misses, at the
> intermediate and final destinations, so they're worth avoiding. That
> makes long-ranged branches worth having. Naturally, they conflict to some
> degree with dense encoding.
<
But a branch all the way over there in 1 instruction has to be better than
a branch ½ way and then another branch ½ way. Branches are latency !
GBOoO machines can hid a lot of it, but they are latency nonetheless.
>
>
> John

On 4/1/2023 2:14 PM, MitchAlsup wrote:
> On Saturday, April 1, 2023 at 1:55:35 PM UTC-5, BGB wrote:
>> On 3/31/2023 4:24 PM, robf...@gmail.com wrote:
>>> On Friday, March 31, 2023 at 4:16:12 PM UTC-4, John Dallman wrote:
>>>> In article <0904a0d8-d657-4176...@googlegroups.com>,
>>>> robf...@gmail.com () wrote:
>>>>
>>>>> And, I would like to get rid of program counter relative addressing
>>>>> and use function address offsets. That way all displacements could
>>>>> be positive offsets.
>>>> Setting a hard upper limit on the size of a function is rather brave. How
>>>> would a function that exceeded it be executed?
>>>>
>>>> John
>>>
>>> Regarding internal branching also non-PC relative. A 16-bit offset
>>> is likely enough to cover the majority of cases.
>>>
>>> Most functions are 4kB or less. If writing a function over 64kB in length
>>> there may be something wrong with the code structure. It could be broken
>>> up into smaller functions.
> <
> That 16-bit flow control displacement covers 256KB of code (not 64KB).
> <
>>> Otherwise a second pointer register would need to be updated with a
>>> reasonable value to branch offset from. I think ugly, but not impossible.
>>>
>> If the ISA breaks in some fundamental way because someones' "switch()"
>> or similar is just a little too big, this isn't ideal...
> <
> {In gomer Pyle's best voice}
> Surprise, surprise, surprise........
>>
>> Better to just stick with ye olde PC relative branches IMHO.
>>
>>
>> As for displacement, 16-bit would probably be fine.
> <
> At the 99.8% level, yes; at 6-sigma, no.
>>
>> In BJX2, I initially started with 16-bit branches, but then later went
>> to 20 bit as I wanted to be able to have branches reach across the
>> entire ".text" section for a typical program.
> <
> I have 16-bit conditional branches and 26-bit unconditional branches
> and Calls. These suffice (again at the 99.8% level) for single modules
> coming out of the linker.
> <
> But no displacement suffices for dynamic external data or function
> linkages.
>>
>> But, then initially spent dedicated encoding space for BT/BF Disp20,
>> which are now deprecated and may be later removed (such that the
>> encoding space can be reclaimed). The replacement being to encode "BT/BF
>> Disp20" as "BRA?T/F Disp20" (as predicated ops had previously been
>> promoted to being part of the core ISA).
>>
>>
>> There are some branch forms with an 8-bit displacement, but these are a
>> little weak, as an 8-bit displacement is hit-or-miss even for "if()"
>> blocks and "while()" loops.
>>
> I got 16-bit conditional and 26-bit unconditional branch displacements
> and never found the need for more (subject to dynamic external linking.)

20 bits is mostly sufficient, except that my ROTT port is currently
pushing the limits.

>>
>> I had considered adding a possible "Bcc Rn, Disp12" encoding. This would
> <
> So you started with 16, then added 20 later to be deprecated, then added 8
> and now you are looking for 12. It seems to me that a rethink in the encoding
> that would accommodate all flavors more uniformly is in order.
> <

I had started with:
F0dd_20dd BRA Disp16
F0dd_21dd BSR Disp16
F0dd_22dd BT Disp16
F0dd_23dd BF Disp16

But, these were soon replaced, and this block now contains 3R ops.
The Disp20 replacements were at:
F0dd_Cddd .. F0dd_Fddd

"BRA Disp20" and "BSR Disp20" are still mainline.

"BT Disp20" and "BF Disp20" were deprecated for being redundant with
"BRA?T Disp20" and "BRA?F Disp20", the latter becoming the new canonical
ways to encode these instructions.

BT?T/BT?F/BF?T/BF?F sorta existed in the encoding space, but are
essentially invalid.

The Disp8s forms were for Compare-and-Branch encodings, where the
"Compare Rn with Zero and Branch" case has at least some usefulness.
However, the Disp8s (+/- 256 bytes), isn't really sufficient (and in
many cases where they could be used, they are not, because the target
label isn't close enough).

The main incentive for these is that they could save a few cycles per
loop iteration in a few cases (vs a CMPxx+BT/BF pair).

>> cover most normal loops. But, still debatable vs CMPxx+BT/BF. Would need
>> to decide some between spending 6 of the 16 Disp12 spots on the branch
>> cases, or merely 3, with predication encoding the other part.
>>
>> BNE Rn, Disp12 => BEQ?F Rn, Disp12
>> BLE Rn, Disp12 => BGT?F Rn, Disp12
>> BLT Rn, Disp12 => BGE?F Rn, Disp12
>>
>> Possibly with these ops only being defined for predicated encodings (the
>> unconditional forms encoding "something else").
>>
>> Or try to find some "odd corner" to stick it into (vs spending encoding
>> space in the F8 block).
>>
>> Say:
>> The space occupied by BT?T/BT?F gets reused for these:
>> E0dd_Eeod => Bcc?T Ro, Disp12
>> E4dd_Eeod => Bcc?F Ro, Disp12
>> With the En/Em bits encoding the CC:
>> 00 = EQ / NE
>> 01 = GT / LE
>> 10 = GE / LT
>> 11 = ?
>> The Eq bit would select between a 32 and 64 bit comparison.
>>
>> Though, this would preclude being able to later reclaim this space for
>> normal 3R ops. However, as-is, these encodings are effectively invalid.
>>
>> Could also overlap it with BSR, but this leaves an issue for whether
>> BSR?T / BSR?F should be left open as a possibility.
>>
>> ...
>>
>>
>>>

On Saturday, April 1, 2023 at 2:55:35 PM UTC-4, BGB wrote:
> On 3/31/2023 4:24 PM, robf...@gmail.com wrote:
> > On Friday, March 31, 2023 at 4:16:12 PM UTC-4, John Dallman wrote:
> >> In article <0904a0d8-d657-4176...@googlegroups.com>,
> >> robf...@gmail.com () wrote:
> >>
> >>> And, I would like to get rid of program counter relative addressing
> >>> and use function address offsets. That way all displacements could
> >>> be positive offsets.
> >> Setting a hard upper limit on the size of a function is rather brave. How
> >> would a function that exceeded it be executed?
> >>
> >> John
> >
> > Regarding internal branching also non-PC relative. A 16-bit offset
> > is likely enough to cover the majority of cases.
> >
> > Most functions are 4kB or less. If writing a function over 64kB in length
> > there may be something wrong with the code structure. It could be broken
> > up into smaller functions.
> > Otherwise a second pointer register would need to be updated with a
> > reasonable value to branch offset from. I think ugly, but not impossible.
> >
> If the ISA breaks in some fundamental way because someones' "switch()"
> or similar is just a little too big, this isn't ideal...
>
> Better to just stick with ye olde PC relative branches IMHO.
>
Yes, it is probably the best approach overall. Performance has won out.

Decided to go with a 2-bits page relative, 14-bits page offset style of
branching. It is shaving bits off the adder chain for branch displacements and
saving LUTs. Conditional branches are 2,14; unconditional branches can use
a 14-bit page relative, 14-bit page offset form for 28-bits effectively. Only a
14-bit branch PC adder is needed then.

It has made it easier to verify the assembler as the low 14 bits can be easily
seen in the instruction opcode. However, generating relocation records for the
split addressing was a challenge. Treated as two separate relocations.

>
> As for displacement, 16-bit would probably be fine.
>
> In BJX2, I initially started with 16-bit branches, but then later went
> to 20 bit as I wanted to be able to have branches reach across the
> entire ".text" section for a typical program.
>
> But, then initially spent dedicated encoding space for BT/BF Disp20,
> which are now deprecated and may be later removed (such that the
> encoding space can be reclaimed). The replacement being to encode "BT/BF
> Disp20" as "BRA?T/F Disp20" (as predicated ops had previously been
> promoted to being part of the core ISA).
>
>
> There are some branch forms with an 8-bit displacement, but these are a
> little weak, as an 8-bit displacement is hit-or-miss even for "if()"
> blocks and "while()" loops.
>
>
> I had considered adding a possible "Bcc Rn, Disp12" encoding. This would
> cover most normal loops. But, still debatable vs CMPxx+BT/BF. Would need
> to decide some between spending 6 of the 16 Disp12 spots on the branch
> cases, or merely 3, with predication encoding the other part.
>
> BNE Rn, Disp12 => BEQ?F Rn, Disp12
> BLE Rn, Disp12 => BGT?F Rn, Disp12
> BLT Rn, Disp12 => BGE?F Rn, Disp12
>
> Possibly with these ops only being defined for predicated encodings (the
> unconditional forms encoding "something else").
>
> Or try to find some "odd corner" to stick it into (vs spending encoding
> space in the F8 block).
>
> Say:
> The space occupied by BT?T/BT?F gets reused for these:
> E0dd_Eeod => Bcc?T Ro, Disp12
> E4dd_Eeod => Bcc?F Ro, Disp12
> With the En/Em bits encoding the CC:
> 00 = EQ / NE
> 01 = GT / LE
> 10 = GE / LT
> 11 = ?
> The Eq bit would select between a 32 and 64 bit comparison.
>
> Though, this would preclude being able to later reclaim this space for
> normal 3R ops. However, as-is, these encodings are effectively invalid.
>
> Could also overlap it with BSR, but this leaves an issue for whether
> BSR?T / BSR?F should be left open as a possibility.
>
> ...
>
It sounds like your ISA is supporting legacy code from earlier versions.
IMHO it is best to stick to only a couple of branch formats otherwise
there is a lot muxing on branch fields.
>
> >

On Saturday, April 1, 2023 at 3:14:51 PM UTC-4, MitchAlsup wrote:
> On Saturday, April 1, 2023 at 1:55:35 PM UTC-5, BGB wrote:
> > On 3/31/2023 4:24 PM, robf...@gmail.com wrote:
> > > On Friday, March 31, 2023 at 4:16:12 PM UTC-4, John Dallman wrote:
> > >> In article <0904a0d8-d657-4176...@googlegroups.com>,
> > >> robf...@gmail.com () wrote:
> > >>
> > >>> And, I would like to get rid of program counter relative addressing
> > >>> and use function address offsets. That way all displacements could
> > >>> be positive offsets.
> > >> Setting a hard upper limit on the size of a function is rather brave.. How
> > >> would a function that exceeded it be executed?
> > >>
> > >> John
> > >
> > > Regarding internal branching also non-PC relative. A 16-bit offset
> > > is likely enough to cover the majority of cases.
> > >
> > > Most functions are 4kB or less. If writing a function over 64kB in length
> > > there may be something wrong with the code structure. It could be broken
> > > up into smaller functions.
> <
> That 16-bit flow control displacement covers 256KB of code (not 64KB).

Thor's code is byte aligned, so 16-bits only cover 64kB. I thought of bundling
40-bit instructions in 128-bit strips which would allow two extra bits for
displacements. But it would waste 1/16 of memory.

There may yet be two more bits available for branches, if an eight bit
immediate for compare were limited to six bits. Which is more valuable?
Two extra bits of branch displacement or two extra bits when comparing
immediates? Thor can handle branch compares to small immediate
values.

> <
> > > Otherwise a second pointer register would need to be updated with a
> > > reasonable value to branch offset from. I think ugly, but not impossible.
> > >
> > If the ISA breaks in some fundamental way because someones' "switch()"
> > or similar is just a little too big, this isn't ideal...
> <
> {In gomer Pyle's best voice}
> Surprise, surprise, surprise........
> >
> > Better to just stick with ye olde PC relative branches IMHO.
> >
> >
> > As for displacement, 16-bit would probably be fine.
> <
> At the 99.8% level, yes; at 6-sigma, no.
> >
> > In BJX2, I initially started with 16-bit branches, but then later went
> > to 20 bit as I wanted to be able to have branches reach across the
> > entire ".text" section for a typical program.
> <
> I have 16-bit conditional branches and 26-bit unconditional branches
> and Calls. These suffice (again at the 99.8% level) for single modules
> coming out of the linker.
> <
> But no displacement suffices for dynamic external data or function
> linkages.
> >
> > But, then initially spent dedicated encoding space for BT/BF Disp20,
> > which are now deprecated and may be later removed (such that the
> > encoding space can be reclaimed). The replacement being to encode "BT/BF
> > Disp20" as "BRA?T/F Disp20" (as predicated ops had previously been
> > promoted to being part of the core ISA).
> >
> >
> > There are some branch forms with an 8-bit displacement, but these are a
> > little weak, as an 8-bit displacement is hit-or-miss even for "if()"
> > blocks and "while()" loops.
> >
> I got 16-bit conditional and 26-bit unconditional branch displacements
> and never found the need for more (subject to dynamic external linking.)
> >
> > I had considered adding a possible "Bcc Rn, Disp12" encoding. This would
> <
> So you started with 16, then added 20 later to be deprecated, then added 8
> and now you are looking for 12. It seems to me that a rethink in the encoding
> that would accommodate all flavors more uniformly is in order.
> <
> > cover most normal loops. But, still debatable vs CMPxx+BT/BF. Would need
> > to decide some between spending 6 of the 16 Disp12 spots on the branch
> > cases, or merely 3, with predication encoding the other part.
> >
> > BNE Rn, Disp12 => BEQ?F Rn, Disp12
> > BLE Rn, Disp12 => BGT?F Rn, Disp12
> > BLT Rn, Disp12 => BGE?F Rn, Disp12
> >
> > Possibly with these ops only being defined for predicated encodings (the
> > unconditional forms encoding "something else").
> >
> > Or try to find some "odd corner" to stick it into (vs spending encoding
> > space in the F8 block).
> >
> > Say:
> > The space occupied by BT?T/BT?F gets reused for these:
> > E0dd_Eeod => Bcc?T Ro, Disp12
> > E4dd_Eeod => Bcc?F Ro, Disp12
> > With the En/Em bits encoding the CC:
> > 00 = EQ / NE
> > 01 = GT / LE
> > 10 = GE / LT
> > 11 = ?
> > The Eq bit would select between a 32 and 64 bit comparison.
> >
> > Though, this would preclude being able to later reclaim this space for
> > normal 3R ops. However, as-is, these encodings are effectively invalid.
> >
> > Could also overlap it with BSR, but this leaves an issue for whether
> > BSR?T / BSR?F should be left open as a possibility.
> >
> > ...
> >
> >
> > >

On 4/1/2023 7:38 PM, robf...@gmail.com wrote:
> On Saturday, April 1, 2023 at 2:55:35 PM UTC-4, BGB wrote:
>> On 3/31/2023 4:24 PM, robf...@gmail.com wrote:
>>> On Friday, March 31, 2023 at 4:16:12 PM UTC-4, John Dallman wrote:
>>>> In article <0904a0d8-d657-4176...@googlegroups.com>,
>>>> robf...@gmail.com () wrote:
>>>>
>>>>> And, I would like to get rid of program counter relative addressing
>>>>> and use function address offsets. That way all displacements could
>>>>> be positive offsets.
>>>> Setting a hard upper limit on the size of a function is rather brave. How
>>>> would a function that exceeded it be executed?
>>>>
>>>> John
>>>
>>> Regarding internal branching also non-PC relative. A 16-bit offset
>>> is likely enough to cover the majority of cases.
>>>
>>> Most functions are 4kB or less. If writing a function over 64kB in length
>>> there may be something wrong with the code structure. It could be broken
>>> up into smaller functions.
>>> Otherwise a second pointer register would need to be updated with a
>>> reasonable value to branch offset from. I think ugly, but not impossible.
>>>
>> If the ISA breaks in some fundamental way because someones' "switch()"
>> or similar is just a little too big, this isn't ideal...
>>
>> Better to just stick with ye olde PC relative branches IMHO.
>>
> Yes, it is probably the best approach overall. Performance has won out.
>
> Decided to go with a 2-bits page relative, 14-bits page offset style of
> branching. It is shaving bits off the adder chain for branch displacements and
> saving LUTs. Conditional branches are 2,14; unconditional branches can use
> a 14-bit page relative, 14-bit page offset form for 28-bits effectively. Only a
> 14-bit branch PC adder is needed then.
>
> It has made it easier to verify the assembler as the low 14 bits can be easily
> seen in the instruction opcode. However, generating relocation records for the
> split addressing was a challenge. Treated as two separate relocations.
>

OK.

In my case, I am using a modified version of the PE/COFF base-relocation
tables. Mostly adding tweaks to deal with some BJX2-specific ways of
encoding addresses, and some features which are specific to my ABI
design (such as PBO fixups, *1).

*1: Programs access all of their data sections via GBR, but the program
needs to be able to get back to its own GBR from any other GBR within
the same logical process.
So, GBR(0) points to a table of pointers to GBR's for this process, and
it is necessary to fixup the offset into this table.

Essentially, say:
MOV.Q (GBR, 0), R3
//Special reloc points here:
MOV.Q (R3, Index), R3
MOV R3, GBR

Each DLL or similar being loaded getting its own index (the main EXE
implicitly always keeps the index 0).
Initially, GBR(0) is a self-pointer, so with a "simple loader" (like
that used by the Boot ROM), the above sequence will simply get back to
the initial GBR.

OTOH, there are not a whole lot of address fixups in the code sections
(pretty much everything being PC relative or GBR relative).

As I saw it, this seemed preferable to the FDPIC approach (but, the GBR
reload handling still isn't free).

>>
>> As for displacement, 16-bit would probably be fine.
>>
>> In BJX2, I initially started with 16-bit branches, but then later went
>> to 20 bit as I wanted to be able to have branches reach across the
>> entire ".text" section for a typical program.
>>
>> But, then initially spent dedicated encoding space for BT/BF Disp20,
>> which are now deprecated and may be later removed (such that the
>> encoding space can be reclaimed). The replacement being to encode "BT/BF
>> Disp20" as "BRA?T/F Disp20" (as predicated ops had previously been
>> promoted to being part of the core ISA).
>>
>>
>> There are some branch forms with an 8-bit displacement, but these are a
>> little weak, as an 8-bit displacement is hit-or-miss even for "if()"
>> blocks and "while()" loops.
>>
>>
>> I had considered adding a possible "Bcc Rn, Disp12" encoding. This would
>> cover most normal loops. But, still debatable vs CMPxx+BT/BF. Would need
>> to decide some between spending 6 of the 16 Disp12 spots on the branch
>> cases, or merely 3, with predication encoding the other part.
>>
>> BNE Rn, Disp12 => BEQ?F Rn, Disp12
>> BLE Rn, Disp12 => BGT?F Rn, Disp12
>> BLT Rn, Disp12 => BGE?F Rn, Disp12
>>
>> Possibly with these ops only being defined for predicated encodings (the
>> unconditional forms encoding "something else").
>>
>> Or try to find some "odd corner" to stick it into (vs spending encoding
>> space in the F8 block).
>>
>> Say:
>> The space occupied by BT?T/BT?F gets reused for these:
>> E0dd_Eeod => Bcc?T Ro, Disp12
>> E4dd_Eeod => Bcc?F Ro, Disp12
>> With the En/Em bits encoding the CC:
>> 00 = EQ / NE
>> 01 = GT / LE
>> 10 = GE / LT
>> 11 = ?
>> The Eq bit would select between a 32 and 64 bit comparison.
>>
>> Though, this would preclude being able to later reclaim this space for
>> normal 3R ops. However, as-is, these encodings are effectively invalid.
>>
>> Could also overlap it with BSR, but this leaves an issue for whether
>> BSR?T / BSR?F should be left open as a possibility.
>>
>> ...
>>
> It sounds like your ISA is supporting legacy code from earlier versions.
> IMHO it is best to stick to only a couple of branch formats otherwise
> there is a lot muxing on branch fields.

There is still some amount of cruft that has built up. My compiler has
an excessive amount of cruft at this point, but haven't gotten around to
rewriting it (I initially used a quick and dirty backend design which
made sense for SH-4; but has quickly turned into a mess as my ISA has
since drifted a bit far from being SH-4 ...).

During the course of early development, the ISA had undergone multiple
reorganizations and encoding changes, but settled on the current
encoding scheme in roughly 2020.

But, as noted, an early form of the ISA had 16-bit branches:
F0dd_20dd //these no longer exist
With a baseline instruction format:
F0eo_ZZnm //changed

Slightly later, this was changed to the current:
F0nm_ZeoZ

Roughly around the time I added the F1 and F2 blocks (mostly as I didn't
like the idea of the F1/F2 and F0 blocks having entirely different
instruction layouts).

Though, the F8 block was left as-is, which broke symmetry:
F0en_30ZZ //1R space
F8Zn_iiii //16-bit ops
Now:
F0ZZ_3en0 //1R space
F8Zn_iiii //16-bit ops

But, at the time, it didn't seem there was any good way to make Imm16
ops consistent with the rest of the ISA, and would:
F8ii_iZni //?
Actually have been an improvement, I suspect, probably not...

In the early form of the ISA, it was mostly using Imm5 / Disp5 fields,
but it didn't take long to realize that 5-bit immediate and displacement
fields "fell a little short".

But, Imm5/Disp5 encodings did partially come back later...
Some of the original Imm5 spots did end up getting replaced by 128-bit
SIMD ops and similar instead.

The original ISA was also 16/32/48 bit ops, but a later encoding change
(adding Jumbo prefixes) effectively nuked the original 48-bit ops (the
Jumbo Prefixes ate their encoding space).

At this point, the ISA went from 16/32/48 to 16/32/64/96.

Had debated partly re-adding them, say:
FEzz_zzzz-Xzzz
FFzz_zzzz-Xzzz
Where X excludes {7,9,E,F}.

Have yet to fully decide on an encoding, or whether they would be a good
idea (re-adding 48-bit ops would also re-add some of the problems that
were solved by dropping support for 48-bit ops). The only possible merit
they would have is the ability to be slightly more compact than 64-bit
ops, but as-is, 64-bit ops are typically fairly uncommon, so this
wouldn't save much.

The biggest "recent" break being the creation of XG2 Mode, but XG2 Mode
isn't really a good "replacement" for the Baseline ISA. XG2 makes sense
for performance-oriented code (and makes things a little more
orthogonal); but adversely effects code density, and still doesn't fully
resolve some of the encoding woes (where "what I actually want", sadly,
can't be fit into a 32-bit instruction format; but going to a bigger
instruction format would make some issues worse).

As-is, XG2 mode also introduces some similar annoyances to Thumb mode on
ARM (just with the ISA roles partially reversed).

On 3/24/23 8:12 PM, MitchAlsup wrote:
> On Friday, March 24, 2023 at 4:44:26 PM UTC-5, Kent Dickey wrote:
[snip]
>> CXL also adds a way to add memory on PCIe which host CPUs can use as more
>> coherent memory (which may be in another computer), and I wasn't referring
>> to that.
> <
> This is mostly being sold as:: you can eliminate the DRAM I/O pins and
> put everything on PCIe. For something like a modern x86-64 chip, you
> save 200 DRAM pins and add a couple (4) CXL popcorn parts to access
> DRAM.

While PCIe might well be very bandwidth efficient for a commodity
standard for general use, I suspect one could get a little more
effective bandwidth with a specialized interface, especially if
one can assume tighter integration and higher quality
implementation.

I am probably also a little of a latency fanboi — promoting
latency as important not because it has been measured to be so but
because I happened to land on that side of the conflict. Adding a
translation layer and a chip hop seems likely to increase latency.

(Caches do work surprisingly well and avoiding the cache checking
latency overhead is difficult and some on-chip network delay is
unavoidable in the general case — in the special case of a core
being close to the memory controller it primarily (or urgently)
uses. Checking an L3 filter or predictor in parallel with L2 tags
might be practical, but I suspect the cost would not be worth the
benefit.)

> It also decouples the CPU chips from DRAM I/O protocols. Enabling more
> use of HBM........

Buffered memory (e.g., FB-DIMM) had a similar benefit but did not
seem to lead to diversity.

An intermediate chip could also provide caching, prefetch
buffering, and coherence (if connected to more than one node).
Extra connections might also expand memory (or cache) capacity or
provide communication routes. Connecting to a networking chip
would seem to facilitate lower overhead send DMA for non-dynamic
data (dynamic data would be more reasonably sources from processor
caches, I suspect). With a more generic interface (like PCIe),
bandwidth could be shared between memory accesses and I/O accesses
(like old system's buses sharing the bandwidth between I/O and
memory).

As a latency fanboi, I am disappointed by HBM because it trades
price per bit for bandwidth but no similar product has succeeded
in trading price per bit for lower latency. Fanboi sad.☹

On 3/9/23 2:28 PM, MitchAlsup wrote:
> On Wednesday, March 8, 2023 at 4:28:05 PM UTC-6, robf...@gmail.com wrote:
> <
>> I like the 64kB page size.
> <
> As always there are benefits and detriments to this size of page.
> There is a never ending tension between smaller page sizes so
> processes/threads can share stuff more efficiently;

This assumes that permissions are tied to translation units. Even
without capabilities, this need not be the case. A global address
space as proposed for the Mill would naturally defer translation
(and possibly also make cross-application sharing easier, possibly
at the cost of side channels [any resource sharing seems
susceptible to side channels]), so even if the permissions used
the same granularity there might be a separation of storage (or
caching) since permissions are needed at access but translation is
only needed to route the request to the appropriate memory
controller (this seems to raise some interesting issues).

With separate caching storage near the agent/core, different
granularity may make sense. Permissions may also favor merging
into "superpages" more than even 4KiB pages do for translations.
(AMD produced a TLB that merges a cache line to PTEs into a single
TLB entry if the translations form a superpage; this "requires"
high associativity — full in AMD's case — since non-coalesced
pages in a virtual chunk would share the same index.)

(At extreme page sizes or sparse allocation, internal
fragmentation could also be a problem. Smaller processes — perhaps
for greater resilience/fault containing — would also seem to
encourage smaller permission granules. In-memory compression would
seem to help with memory consumption [unused/zeroed memory would
compress well] in this case but introduces other overheads.)

> then there is
> the larger page sizes have better TLB performance:: but you also
> have the effect, when paging, that larger pages have greater
> swap-in and swap-out latencies.

When smaller pages are effectively used as larger pages,
coalescing becomes possible. There are also tricks like supporting
holes in translation (Chang Hyun Park et al., "Perforated Page:
Supporting Fragmented Memory Allocation for Large Pages", 2020) or
mapping a large page to a shadow memory address which is
translated at the memory controller (Mark Swanson, Leigh Stoller,
and John Carter, "Increasing TLB Reach Using Superpages Backed by
Shadow Memory").

(Reducing the cost of moving pages would seem to also facilitate
defragmentation.)

Even with some sparsity and non-contiguous pages, large virtual
address spaces could still use larger pages to reduce the number
of translation layers. With 5-bit translation levels (with 8-byte
PTEs, 256-byte page table pages), two levels could be merged to
the more ordinary 10-bit translation level (8 KiB page table
page), three levels could be merged to 15-bit (256 KiB), etc. With
10-bit translation layers, there would be less opportunity, but if
a process will be using a large virtual address region (8 GiB)
somewhat densely, then using a 2 MiB translation page to skip a
layer might be useful. (Smaller translation layers also provide
more diverse node-sized pages, though it complicates the choice of
translation level page size. On the other hand, converting a 256-
byte translation layer to a 8 KiB layer would not seem to be that
expensive. Smaller layers do provide fewer bits since the smaller
alignment provides fewer implicit bits.)

(Obviously, nested page tables for virtualization are likely to be
friendlier to large pages.)

> So, if a 4KB page is read/written by I/O device in 1ms, the 64KB
> page will take 16ms. Sooner or later all this extra latency will add
> up..........For exactly the same reasons base-bounds translation
> systems changed as they went from 19-bit address spaces to 32-bit
> address spaces. One could read/write a 18-bit process in a few
> milliseconds, whereas swapping a 30-bit VA could take over 1 minute,
> 1 minute where the CPU was doing nothing !!! because 1 30-bit VaS
> application was being swapped out to make room for another 30-bit
> VaS application in a system with just 31-bit of PaS.

This also seems to get into other considerations such as the file
system interface. An mmap-oriented operating system would seem to
have tighter binding between I/O size and page size.

Flash drives seem to have interestingly different tradeoffs in
that the erase granule is larger than the write granule. (Shingled
disk drives also seem to have interesting tradeoffs.) I have not
looked at such closely, but these factors would seem to influence
ideal I/O size.

(Batch scheduling with long running processes would also seem to
be more tolerant of swapping latency. Using overlaying techniques
might also reduce the overhead as a sort of intermediate between
full process swapping and abstracted paging; perhaps a process
could set values on various memory regions and the scheduler could
choose which "segments" to swap out. Such a crazy design might
also consider scheduling choices not just by priority but also
consider throughput impacts, perhaps letting a lower priority but
memory and storage I/O light program to run since it could start
earlier and would not interfere while more memory is swapped out
in preparation for a larger higher priority program.)

> This is the other side of the tension. More short I/O events versus
> fewer longer I/O events. {In any event, paging won over swapping.}
> <
>> Higher order bits are gained in the PTEs
>> allowing
> <
> All sorts of schemes to make memory management easier/better.
> <
> For example, consider a PTP containing a ASID for the space being
> mapped. So, ASID ceases to be attached at the hip to a thread/process
> but becomes an identifier as to which addresses spaces are being
> shared. Thus, everybody sharing space X, uses ASID[X], optimizing
> sharing in all the HW facilities used to perform mapping.

HP PA-RISC had "Access IDs" as part of the PTEs, which had to
match one of eight "Protection ID Registers". (Itanium had similar
"Protection Keys" but with a minimum of 16 registers and the
ability for the register to disable reads and executes as well as
write disable provided by PA-RISC.) In theory one could also
define "global" key values that always match (and so do not
require a register entry — perhaps I am remembering this from it
actually being implemented); with no disable bits provided such
would provide low cost ID registers, alternatively modifiable
disable bits could be provided such that the savings was "only" in
the ID match possibly checking if all but three bits are zero and
using those to reference an 8-etnry disable bits table.

This is one way of facilitating single address space systems.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 3/20/2023 7:20 AM, Anton Ertl wrote:
>>
>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>
>>>> (-1)/2 is not a shift except in ones-comp and sign-mag.
>>>
>>> Sure is:
>>>
>>> -1 2 / .
>>> -1 1 arshift .
>>>
>>> Running Gforth 0.7.9_20230317, both output "-1".
>>>
>>> Do you mean to tell me that the Mill has all kinds of options for
>>> dealing with overflow, but does not support floored or Euclidean (same
>>> results for positive divisors) division?
>>
>> Looks like you assume round toward -inf. Why?
>
> Because it has much nicer behaviour when the dividend crosses 0 than
> round-towards-0 has:
>
> round-towards-0 (aka truncated):
>
> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>
> round towards -inf (floored):
>
> https://en.wikipedia.org/wiki/File:Divmod_floored.svg

Nicer behavior is in the eye of the beholder.

The graph for round towards -inf may look more pleasing to
the eye.

But round towards zero is mathematically nicer:

(-x)/y == - (x/y)

To me the mathematical picture is the more important one.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[floored division]
>> Because it has much nicer behaviour when the dividend crosses 0 than
>> round-towards-0 has:
>>
>> round-towards-0 (aka truncated):
>>
>> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>>
>> round towards -inf (floored):
>>
>> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
>
>Nicer behavior is in the eye of the beholder.
>
>The graph for round towards -inf may look more pleasing to
>the eye.
>
>But round towards zero is mathematically nicer:
>
> (-x)/y == - (x/y)

But round towards -inf is mathematically nicer:

(x+y)/y = (x/y)+1

And in practice, that's more frequently useful.

>To me the mathematical picture is the more important one.

People who prefer floored or Euklidean division also give mathematical
arguments.

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

On Friday, July 21, 2023 at 8:39:44 AM UTC+3, Anton Ertl wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
> >an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> [floored division]
> >> Because it has much nicer behaviour when the dividend crosses 0 than
> >> round-towards-0 has:
> >>
> >> round-towards-0 (aka truncated):
> >>
> >> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
> >>
> >> round towards -inf (floored):
> >>
> >> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
> >
> >Nicer behavior is in the eye of the beholder.
> >
> >The graph for round towards -inf may look more pleasing to
> >the eye.
> >
> >But round towards zero is mathematically nicer:
> >
> > (-x)/y == - (x/y)
> But round towards -inf is mathematically nicer:
>
> (x+y)/y = (x/y)+1
>
> And in practice, that's more frequently useful.

Yes. For me the most important advantage is ease of
implementing a ratio rounded to nearest.
Assuming positive y and flooring division it's as simple as
rnd_rat = (2*x + y)/(2*y)
I know of no similarly simple way with truncating division.

However, it seems that in majority of programming/HDL
languages truncating division won.

> >To me the mathematical picture is the more important one.
> People who prefer floored or Euklidean division also give mathematical
> arguments.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>However, it seems that in majority of programming/HDL
>languages truncating division won.

I don't have an easy way to count the entries in the table at
<https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
it seems to me that a lot of languages offer several options:
Truncated (symmetric) and one of floored or Euclidean (which produce
the same results for positive divisors); some only offer truncated,
but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
PureScript, Stata, Z3).

[Tim Rentsch:]
>> >To me the mathematical picture is the more important one.

It's interesting that the more mathematically-oriented languages like
APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
remainder, so I guess that the "mathematical picture" argues against
truncated (round-towards-0) division.

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

On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >However, it seems that in majority of programming/HDL
> >languages truncating division won.
> I don't have an easy way to count the entries in the table at
> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> it seems to me that a lot of languages offer several options:
> Truncated (symmetric) and one of floored or Euclidean (which produce
> the same results for positive divisors); some only offer truncated,
> but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> PureScript, Stata, Z3).
>
> [Tim Rentsch:]
> >> >To me the mathematical picture is the more important one.
> It's interesting that the more mathematically-oriented languages like
> APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> remainder, so I guess that the "mathematical picture" argues against
> truncated (round-towards-0) division.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

I never used any of those languages . There is non-zero chance that I'd
learn R eventually. For the rest of them, I don't see a reason.
The only "mathematically-oriented" language that I use regularly (daily) is
Matlab/Octave. It seems that Matlab does not have integer division operation
at all. In Octave it can be achieved although I'd guess that majority of users
are not aware of that. It is truncating which is not surprising given Fortran
heritage of Matlab and Fortran/C heritage of Octave.

Michael S <already5chosen@yahoo.com> writes:
>On Friday, July 21, 2023 at 4:09:35=E2=80=AFPM UTC+3, Anton Ertl wrote:
>> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but=20
....
>The only "mathematically-oriented" language that I use regularly (daily) is=
>=20
>Matlab/Octave. It seems that Matlab does not have integer division operatio=
>n
>at all.

According to the page above, MATLAB has mod (floored) and rem
(truncated). Octave is not listed.

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

On Friday, July 21, 2023 at 5:31:11 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Friday, July 21, 2023 at 4:09:35=E2=80=AFPM UTC+3, Anton Ertl wrote:
> >> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but=20
> ...
> >The only "mathematically-oriented" language that I use regularly (daily) is=
> >=20
> >Matlab/Octave. It seems that Matlab does not have integer division operatio=
> >n
> >at all.
>
> According to the page above, MATLAB has mod (floored) and rem
> (truncated). Octave is not listed.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Matlab (and Octave) rem() and mod() are floating point operations rather
than integer.

Michael S <already5chosen@yahoo.com> writes:
>On Friday, July 21, 2023 at 5:31:11=E2=80=AFPM UTC+3, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Friday, July 21, 2023 at 4:09:35=3DE2=3D80=3DAFPM UTC+3, Anton Ertl w=
>rote:=20
>> >> <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>
....
>> According to the page above, MATLAB has mod (floored) and rem=20
>> (truncated). Octave is not listed.
....
>Matlab (and Octave) rem() and mod() are floating point operations rather
>than integer.=20

The page above is not limited to integer operations. And neither is
the issue at hand: is the quotient rounded towards 0 or towards -inf.

However, the page above lists the MATLAB mod and rem as integer, not
floating-point operations. As a MATLAB user you may want to correct
this (and maybe add Octave).

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

According to Michael S <already5chosen@yahoo.com>:
>However, it seems that in majority of programming/HDL
>languages truncating division won.

I suspect that's an ancient artifact of Fortran originally being
implemented on a machine that did (mostly) sign-magnitude arithmetic.

I also suspect too many programming language designers don't know
enough about numerical analysis to make an informed choice between the
two.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
>According to Michael S <already5chosen@yahoo.com>:
>>However, it seems that in majority of programming/HDL
>>languages truncating division won.
>
>I suspect that's an ancient artifact of Fortran originally being
>implemented on a machine that did (mostly) sign-magnitude arithmetic.

I suspect so, too. So there's an interesting sequence of events:

* Early architectures used sign-magnitude, where truncated/symmetric
division is easiest to implement, and therefore they implemented
symmetric division.

* Fortran wanted to be close to the machine, and therefore also
implemented truncated division.

* So when architectures switched to two's complement, where floored is
not harder to implement than truncated, those who implemented signed
division implemented truncated division for Fortran compatibility.

It's interesting that COBOL and APL, both from the time before the
switch to 2s-complement, implement floored division according to
<https://en.wikipedia.org/wiki/Modulo#In_programming_languages>

>I also suspect too many programming language designers don't know
>enough about numerical analysis to make an informed choice between the
>two.

Forth is an interesting case:

In the Forth-79 standard the division words /, MOD and /MOD are
defined as "round towards 0" (i.e., truncated).

Forth-83 defined division to be floored.

Finally, since Forth-94, it's up to the implementation whether /, MOD,
and /MOD are floored or symmetric (truncated); basically this means
that in portable programs you better use these words only with
positive operands (and that's probably what the majority of uses were
earlier). If you want to write reliable code where the operands can
have different signs, Forth-94 provides FM/MOD (floored) and SM/REM
(symmetric/truncated).

There is also UM/MOD (unsigned) and some implementations have IIRC a
signed/unsigned division, but I don't remember whether they implement
it symmetric or floored.

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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>I suspect that's an ancient artifact of Fortran originally being
>>implemented on a machine that did (mostly) sign-magnitude arithmetic.
>
>I suspect so, too. So there's an interesting sequence of events: ...
>It's interesting that COBOL and APL, both from the time before the
>switch to 2s-complement, implement floored division according to
><https://en.wikipedia.org/wiki/Modulo#In_programming_languages>

For APL it's not surprising. Ken Iverson was a mathematician before he
switched to computing in 1951 working with Howard Aiken and Wassily
Leontief. (If I'd had a chance to work them them, I'd have switched too.)

APL was originally just a paper algorithm language, and wasn't
implemented until several years after Iverson's book came out. So it's
not surprising that it's defined in a way that makes sense mathematically.

The 1960 COBOL report says that "The least significant digit of the
result field will be increased by 1 whenever the most significant
digit of the excess is greater than or equal to 5." unless you say
UNROUNDED in which case it's truncated. Bitsavers is a bit spase on
COBOL but a 1976 IBM DOS COBOL manual says the same thing, with no
mention of a MOD function. Dunno where it came from.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
> [floored division]
>
>>> Because it has much nicer behaviour when the dividend crosses 0
>>> than round-towards-0 has:
>>>
>>> round-towards-0 (aka truncated):
>>>
>>> https://en.wikipedia.org/wiki/File:Divmod_truncated.svg
>>>
>>> round towards -inf (floored):
>>>
>>> https://en.wikipedia.org/wiki/File:Divmod_floored.svg
>>
>> Nicer behavior is in the eye of the beholder.
>>
>> The graph for round towards -inf may look more pleasing to
>> the eye.
>>
>> But round towards zero is mathematically nicer:
>>
>> (-x)/y == - (x/y)
>
> But round towards -inf is mathematically nicer:
>
> (x+y)/y = (x/y)+1

Doesn't look nicer to me.

> And in practice, that's more frequently useful.

I dispute that assertion.

>> To me the mathematical picture is the more important one.
>
> People who prefer floored or Euklidean division also give
> mathematical arguments.

No doubt there exist environments where either is more
convenient. In my experience in the programming
domain, rounding towards zero is more consistent
with the law of least astonishment.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> [Tim Rentsch:]
>
>>>> To me the mathematical picture is the more important one.
>
> It's interesting that the more mathematically-oriented languages
> like APL, J, Mathcad, Mathematica, R, and Z3 don't even provide
> truncated remainder, so I guess that the "mathematical picture"
> argues against truncated (round-towards-0) division.

It's interesting that in C90 which way division worked was
allowed to be implementation defined, but in C99 and later
division is required to be truncating division.

(For integers, of course. Floating point is another story
altogether.)

On Friday, July 21, 2023 at 4:39:36 PM UTC+3, Michael S wrote:
> On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >However, it seems that in majority of programming/HDL
> > >languages truncating division won.
> > I don't have an easy way to count the entries in the table at
> > <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> > it seems to me that a lot of languages offer several options:
> > Truncated (symmetric) and one of floored or Euclidean (which produce
> > the same results for positive divisors); some only offer truncated,
> > but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> > Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> > Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> > PureScript, Stata, Z3).
> >
> > [Tim Rentsch:]
> > >> >To me the mathematical picture is the more important one.
> > It's interesting that the more mathematically-oriented languages like
> > APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> > remainder, so I guess that the "mathematical picture" argues against
> > truncated (round-towards-0) division.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> I never used any of those languages . There is non-zero chance that I'd
> learn R eventually. For the rest of them, I don't see a reason.
> The only "mathematically-oriented" language that I use regularly (daily) is
> Matlab/Octave. It seems that Matlab does not have integer division operation
> at all. In Octave it can be achieved although I'd guess that majority of users
> are not aware of that. It is truncating which is not surprising given Fortran
> heritage of Matlab and Fortran/C heritage of Octave.

Above I was wrong.
After closer examination I understood that there is no difference between Matlab
and Octave scripts - integer division is absent in both of them.
What I originally confused for integer division in Octave was in fact a floating point
(binary64) division followed by rounding of result to nearest integer with ties broken
away from zero.

On Sunday, July 23, 2023 at 3:30:17 PM UTC+3, Michael S wrote:
> On Friday, July 21, 2023 at 4:39:36 PM UTC+3, Michael S wrote:
> > On Friday, July 21, 2023 at 4:09:35 PM UTC+3, Anton Ertl wrote:
> > > Michael S <already...@yahoo.com> writes:
> > > >However, it seems that in majority of programming/HDL
> > > >languages truncating division won.
> > > I don't have an easy way to count the entries in the table at
> > > <https://en.wikipedia.org/wiki/Modulo#In_programming_languages>, but
> > > it seems to me that a lot of languages offer several options:
> > > Truncated (symmetric) and one of floored or Euclidean (which produce
> > > the same results for positive divisors); some only offer truncated,
> > > but some also offer only floored (APL, COBOL, J, LibreOffice, Lua 5,
> > > Mathcad, Mathematica, Excel, MiniTab, MUMPS, PL/1, R, Raku, Scratch,
> > > Snap!, Spin, Solidity, Tcl, Turing) or only Euclidean (ABAP, Algol 68,
> > > PureScript, Stata, Z3).
> > >
> > > [Tim Rentsch:]
> > > >> >To me the mathematical picture is the more important one.
> > > It's interesting that the more mathematically-oriented languages like
> > > APL, J, Mathcad, Mathematica, R, and Z3 don't even provide truncated
> > > remainder, so I guess that the "mathematical picture" argues against
> > > truncated (round-towards-0) division.
> > > - anton
> > > --
> > > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> > I never used any of those languages . There is non-zero chance that I'd
> > learn R eventually. For the rest of them, I don't see a reason.
> > The only "mathematically-oriented" language that I use regularly (daily) is
> > Matlab/Octave. It seems that Matlab does not have integer division operation
> > at all. In Octave it can be achieved although I'd guess that majority of users
> > are not aware of that. It is truncating which is not surprising given Fortran
> > heritage of Matlab and Fortran/C heritage of Octave.
> Above I was wrong.
> After closer examination I understood that there is no difference between Matlab
> and Octave scripts - integer division is absent in both of them.
> What I originally confused for integer division in Octave was in fact a floating point
> (binary64) division followed by rounding of result to nearest integer with ties broken
> away from zero.

More experiments proved that what I said above is also incorrect.
64-bit integer numbers are not converted to IEEE binary64 floats before division.
They somehow preserve all bits of precision. So, it seems that both Matlab and Octave
do have integer division after all or at least something that is very similar to integer division.
And result of division is rounded to nearest with ties broken away from zero.

Michael S <already5chosen@yahoo.com> schrieb:

> 64-bit integer numbers are not converted to IEEE binary64 floats before division.
> They somehow preserve all bits of precision. So, it seems that both Matlab and Octave
> do have integer division after all or at least something that is very similar to integer division.
> And result of division is rounded to nearest with ties broken away from zero.

A weird mixture between floating point and integer arithmetic...

What would be the right term for that, maybe "floppy point arithmetic"?