Forum : 8051
Original Post
| Post Information | Post |
|---|---|
|
January 24, 2007 - 3:49pm
|
For integer numeric operations, it would be useful to have versions of library routines and compiler output which limit on numeric overflow. For example, adding 2 longs long a, b, c; calls L_ADD. The result will overflow if a+b > 2^31. It's possible in 'C' to detect and limit overflow but it is cumbersome. It would be better to have a compiler #pragma select overflow-limited code for +,- and * on bytes, integers and longs. I don't have access to RIDE's library source but I might try it myself if I could have these. regards Steven Pruzina |
We agree that the idea is good.
We are thinking about implementing such a mechanism but even if the change in the library is simple, it means having a double-set of libraries... At the moment, we cannot say when we will do it.
Note that the code for the addition is quite simple (comparing with the division). If you need to test the overflow of the addition only, you can rewrite it in your project (keeping the same naming of the function) to overload the library function. Please use the code below.
Francis
; Long addition with overflow test
my_ADD_cdseg segment code
my_ADD_bitseg segment bit
extrn code (RST_STK4?C, ?C_LOP)
PUBLIC ?C_LADD, ladd_ov
rseg my_ADD_bitseg
ladd_ov : dbit 1 ; flag set when long addition overflows
rseg my_ADD_cdseg
?C_LADD:
LCALL ?C_LOP ; prepare the loop (R2=4..)
clr C
sjmp NXADD
OK_ADDL:
dec R0 ; R0-R1 are used as pointers to operands
dec R1
NXADD: ; loop for the 4 operations
mov A,@R0
addc A,@R1
mov @R0,A
djnz R2,OK_ADDL
mov ladd_ov, C ; keep carry in the overflow flag
LJMP RST_STK4?C ; restore the stack and return
We are thinking about implementing such a mechanism but even if the change in the library is simple, it means having a double-set of libraries... At the moment, we cannot say when we will do it.
Francis:
re double set, I see a possibility for doing this without duplication:
The F0 flag in the PSW is, traditionally, "reserved for compiler use", simply specify that if an overflow occur the F0 will be set on return. This will in no way affect users that assume the 'traditional' no overflow detect, and give those that want to detect it a flag.
Erik
You are right. We could use it for such a purpose.
It's a good idea because it makes the overflow information "reentrant" since PSW is pushed in the IRQ handlers. Thanks for this suggestion.
We now copy the carry into F0 for both "LONG ADDITION" and "LONG SUBSTRACTION" (the information is not easily available for MUL).
The libraries have still to be tested. They will be available for the next release.
Francis
Francis
Thanks for considering this. The libraries should clip the results of an arithmetic overflow (as well as setting a flag). An overflow reverses the sign of a result, usually with extreme results. So clipping is almost always the best response. I would use the clipped arithmetic in each chain of numerical calculations and might check the overflow flag at the end.
The most frequent range-check I do is to clip a long (32 bit) or float into an integer (16 bit). I do this with function calls. in an overflow-proof library this clipping would happen whenever a long is cast to an int.
regards Steven Pruzina
Note that the carry flag is kept for only the 32-bit add/subb. 16-bit operations are performed inline: we could also copy the carry in F0 but it is not done.