Feedback on Int128 unit required

[MathMan]

Hi all,

I made some progress on the Int128 unit. The goal is to provide 128 bit integer types which are as close as possible equal to a new ordinal type. As I am a complete newbie to operator overloading and exception handling I also did some reverse engineering (study of compiled code) to understand how the compiler works with existing ordinal types. Before I continue with the development I would like to clarify some questions that came up so far. To support my questions I have attached a reduced, but compilable extract of the unit.

1. it looks like I have to do all variants for the operator overloads if I want to achieve my goal and also be efficient in the generated code - or am I missing something here?

2. is the way I generate range and overflow exceptions reasonable, or is there a better way to do this?

3. so far I saw that assignments & comparisons are only range checked, arithmetics are range & overflow checked, range checks precede overflow checks which again precede the actual setting of a value. Am I correct with that understanding?

4. on the following Int128 := -QWORD it looks like I can not avoid the implicte, compiler generated range check for -QWORD without the use of an explicite type cast like Int128 := -tInt128( QWORD )?

5. do I need to take action wrt operand aliasing, or is this fully handled by the compiler? I.e. OWord1 := OWord1 * OWord1 needs a temporary buffer for the result, otherwise the computation steps would destroy the source. Looking at the generated code it seems FPC is handling this, but I would like confirmation.

6. so far I used the generic QWORD and INT64 ordinals, especially for the multiply overloads. I wonder how efficient this is on 32 bit platforms, or whether I need to do seperate implementations for these? Can somebody pls have a look at the generated code on a 32 bit platform.

Cheers,
MathMan

[mika]

i have done int128 for myself and pretty much like you (except range checks and overflows).

5. ... OWord1 := OWord1 * OWord1 needs a temporary buffer for the result, otherwise the computation steps would destroy the source.

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

1.   operator *( var O1, O2: tOWord ) O3: tOWord;

or

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

1.   operator *( const O1, O2: tOWord ) O3: tOWord;

yes  (in this case O1 and O3 are the same variable)

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

1.   operator *( O1, O2: tOWord ) O3: tOWord;

no ( O1 by it self is copy of original)

i'm not sure is it's bug of fpc or what?

[MathMan]

i have done int128 for myself and pretty much like you (except range checks and overflows).

5. ... OWord1 := OWord1 * OWord1 needs a temporary buffer for the result, otherwise the computation steps would destroy the source.

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

1.   operator *( var O1, O2: tOWord ) O3: tOWord;

or

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

1.   operator *( const O1, O2: tOWord ) O3: tOWord;

yes  (in this case O1 and O3 are the same variable)

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

1.   operator *( O1, O2: tOWord ) O3: tOWord;

no ( O1 by it self is copy of original)

i'm not sure is it's bug of fpc or what?

Are you sure about the first and second example?

I used FPC 3.0.4/Linux/64 bit and this one generated an intermediate for the result (variable O3) on the stack, called the multiplication and then copied the intermediate back to the defined result variable when resolving OWord1 := OWord1 * OWord1. It did that regardless of declaration as var or const in the operator overload. I didn't check the declaration <none> so far, because var did what I expected. In case of OWord1 := OWord2 * OWord2 no intermediate is created - as expected too.

[jamie]

I've done large numbers myself but I used inline assembler to do so and thus isn't cross platform compatible.
 Its easy with 64 it instructions..

[mika]

Are you sure about the first and second example?

I did test, it's not a thing. Can not recreate the problem. I looked up, it was 2 years ago and not sure about compiler version. It might be as well current trunk at the time.
Sorry for inconvenience that cause my misleading comment.

[MathMan]

Are you sure about the first and second example?

I did test, it's not a thing. Can not recreate the problem. I looked up, it was 2 years ago and not sure about compiler version. It might be as well current trunk at the time.
Sorry for inconvenience that cause my misleading comment.

Mika - I have to apologise. Because of your feedback I looked at things again yesterday evening. Contrary to my earlier understanding I now think you are correct - I must have made mistakes in my analysis earlier. So thanks for bringing this to my attention.

[ad1mt]

I made some progress on the Int128 unit. The goal is to provide 128 bit integer types which are as close as possible equal to a new ordinal type.

This sounds remarkably similar to what I am trying to do, and also what several others have also done.
It seems to me that some co-operation might be productive. Then we might be able to get an easy-to-use big integer library into the FCL.

I would be interested to see what you've done.