¬a\/b wrote:
> this would be an example for using nasm and a c++ compiler all
> together (for doing a 32 bits type that overflow if something goes
> wrong)
>
> using assembly and c++ has some disadvantage (because compiler has to
> use all the same operation for doing something (that i should
> reproduce in assembly))
> then i not understand many function that compiler use in the code
> (that i not add)
>
> but all this has the vantage of reduce written text code
> and if you have to write something that use the structure of type
> "ou32" you have to write more than me
>
> then i would say that type "ou32" is better of your beloved size_t
> that all you use in malloc and all the routines that has to deal with
> arrays
>
> not because is more fast but because it has the controll on overflow
> that size_t can not to have
>
> can you please point out to some error do you see below?
> what do you think on it?
>
> thank you
> -----------------------------------
[assembly code snipped for brevity]

This approach could (maybe) work, but the problem is that (at least in
C, do not know about C++) overflow is well defined for unsigned integers
or in general unsigned quantities. The result of that operation should
"wrap around".

What is NOT defined, is overflow with signed integers. This distinction
is not apparent in the code you posted.

In my opinion, this should be implemented in the compiler. In the
lcc-win32 compiler a compile time option lets you test for overflow each
of the four operations with signed numbers. This has many advantages,
above all it is simpler to use than having a new integer class. Even if
lcc-win32 implements operator overloading as an extension, I think the
code would have too much of a slowdown if for each addition you would
call a function, even if that function is inlined...

Concerning the assembler code you posted, I do not understand why you
test for carry and NOT for overflow. In my implementation at least, I
test for OVERFLOW after each operation and not just for the carry...

jacob