Integer maths > 16 bits

[MarkMLl]

What are the options for 32-, 64- and 128-bit five-function integer maths on devices like the RP2040 and arbitrary RISC-V targets, with minimal external dependencies?

Area of application is hash algorithms etc., with the assumption (please) that hardware support for these will not be available.

MarkMLl

[Thaddy]

All you need is rolls, shifts, and, or, xor, not and a byte array.
This stems from the olden days. Easiest if there are not signs involved.

[MarkMLl]

Actually Thaddy, I need + -  * div mod and shr. I'm /entirely/ capable of writing them in assembler... I'd just rather not.

MarkMLl

[PascalDragon]

What are the options for 32-, 64- and 128-bit five-function integer maths on devices like the RP2040 and arbitrary RISC-V targets, with minimal external dependencies?

At least 32- and 64-bit math should be fully supported at least if you compile the RTL using software floating point (assuming the processor in question does not support the operations in hardware). If hardware support is available then everything should work out fine if you simply compile for the target.

Only for 128-bit math I don't know right now whether we have some suitable unit already.

[MarkMLl]

Only for 128-bit math I don't know right now whether we have some suitable unit already.

ATM it's the 128-bit case that's most interesting, but I thought I'd build up gradually through the other types since they might not (by default at least) be implemented on small chips.

MarkMLl

[MathMan]

Hi MarkMLI,

Take a look at the attached. Though not fully fleshed - missing some stuff for signed integers - it may be a good starting point. External dependency - FPC has to provide support up to 64 bit types, which I understand from PascalDragons response can be assumed.

If you want/need to extend, then pls let me know. Maybe I can help.

Cheers,
MathMan

[440bx]

MathMan, you got a typo in your signature/name.

[MathMan]

MathMan, you got a typo in your signature/name.

Thanks for the heads up - getting lazy with the internal spell checker routines 

[MarkMLl]

Hi MarkMLI,

Take a look at the attached. Though not fully fleshed - missing some stuff for signed integers - it may be a good starting point. External dependency - FPC has to provide support up to 64 bit types, which I understand from PascalDragons response can be assumed.

If you want/need to extend, then pls let me know. Maybe I can help.

Cheers,
MathMan

Many thanks I'll look at that- not necessarily immediately, but definitely.

MarkMLl

[MarkMLl]

I've spent roughly the last day adding 64-bit handling to some units that hash text (for CHAP-style password checking etc.) and inefficiently test for primality, and then moved on to incorporating your 128-bit library.

I've /twice/ been bitten by the same problem: import the types unit but forget the one with the code, and then wonder why operators don't work. It's one of those damn silly things and is of course entirely self-inflicted, but things /almost/ work to an extent that allows one to overlook the obvious cause.

The thing that's really giving me problems is constant handling. The lack of in-expression tuples is obviously a problem, but what's the correct incantation: I'd have expected it to be something like

Code: Pascal  [Select][+][-]

1. const
2. {$if declared(int128types) }
3.   hashed128= tUInt128.Q[qword(0), qword(0)];
4.   primed128= tUInt128.Q[qword(0), qword(0)];
5. {$endif                    }
6.  

but that just results in "Illegal qualifier" ... "Illegal expression" errors.

MarkMLl

[MathMan]

I've spent roughly the last day adding 64-bit handling to some units that hash text (for CHAP-style password checking etc.) and inefficiently test for primality, and then moved on to incorporating your 128-bit library.

I've /twice/ been bitten by the same problem: import the types unit but forget the one with the code, and then wonder why operators don't work. It's one of those damn silly things and is of course entirely self-inflicted, but things /almost/ work to an extent that allows one to overlook the obvious cause.

The thing that's really giving me problems is constant handling. The lack of in-expression tuples is obviously a problem, but what's the correct incantation: I'd have expected it to be something like

Code: Pascal  [Select][+][-]

1. const
2. {$if declared(int128types) }
3.   hashed128= tUInt128.Q[qword(0), qword(0)];
4.   primed128= tUInt128.Q[qword(0), qword(0)];
5. {$endif                    }
6.  

but that just results in "Illegal qualifier" ... "Illegal expression" errors.

MarkMLl

First - thanks that you're spending the time trying it out.

Second - you got me on the constant expressions. I didn't need them so I haven't spent thought on it so far. Let me do some tinkering and get back to you, ok?

MathMan

[MathMan]

Ah, somewhat uninspired that is - the following works for me

Code: Pascal  [Select][+][-]

1. const
2.   Trial1: tUInt128 = ( L:0; H:0 );
3.   Trial2: tUInt128 = ( Q:( 0, 0 ) );
4.  

I did the type system like it is because I thought that I could cover endianess that way. Turns out not possible for constants as

 - in Trial1 FPC does not sort the H,L parts but needs them in the sequence defined. You'll still have to keep two constant definitions depending on endianess

- in Trial2 you simply have an array of UInt64 so you end up as above

Pitty,
MathMan

[MarkMLl]

A/ha/. So basically I'd managed to fumble : and = into the wrong sequence.

I'd suggest that predefined constants for the additive and multiplicative identities and all-bits-set would be useful (actually applies to all types IMO).

I'll post some code for people to laugh at presently.

MarkMLl

[MathMan]

...
I'd suggest that predefined constants for the additive and multiplicative identities and all-bits-set would be useful (actually applies to all types IMO).
...

MarkMLl

Noted - like say Zero128, One128 & Max128? You have a more inspired suggestion?

Beside - I'd probably use the Q-variant of definition, the outer brackets may be superfluous - I didn't check.

[MarkMLl]

I'd suggest Zero128, Unity128 and AllBits128.

At present I'm using the L and H forms, because we know that the compiler will object if the endianess changes. I'm hoping at some point to crank up my surviving SPARC system which will allow a bigendian test...

MarkMLl