Apple-2-SW/prog8
1
0
Fork 0
mirror of https://github.com/irmen/prog8.git synced 2025-10-31 00:16:08 +00:00
Code Issues Projects Releases Wiki Activity

warning in doc about problems when using long + R0/R1 together

Browse Source
This commit is contained in:
Irmen de Jong
2025-10-11 15:36:57 +02:00
parent 07bb5c36bd
commit 1e8ff6f82a
2 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/source/todo.rst
View File

@@ -1,9 +1,6 @@
TODO
====
- optimized translation for pokeX and peekX if address = pointer + uwordoffset.
STRUCTS and TYPED POINTERS
--------------------------
@@ -22,6 +19,7 @@ STRUCTS and TYPED POINTERS
Future Things and Ideas
^^^^^^^^^^^^^^^^^^^^^^^
- can the compiler give a warning if you use R0/R1 in expressions and/or statements together with long integers? (because R0/R1 are likely to be clobbered as temporary storage)
- handle Alias in a general way in LiteralsToAutoVarsAndRecombineIdentifiers instead of replacing it scattered over multiple functions
- After long variable type is completed: make all constants long by default (remove type name altogether), reduce to target type implictly if the actual value fits.
This will break some existing programs that depend on value wrap arounds, but gives more intuitive constant number handling.
@@ -172,7 +170,6 @@ Optimizations
-------------
- optimize inplaceLongShiftRight() for byte aligned cases
- investigate why the c bench Sieve test is slower in prog8 than all of the rest
- more optimized operator handling of different types, for example uword a ^ byte b now does a type cast of b to word first
- optimize longEqualsValue() for const and variable operands to not assign needlessly to R0-R3.
- optimize optimizedBitwiseExpr() for const and variable operands to not assign needlessly to R0-R3.

7
docs/source/variables.rst
View File

@@ -248,8 +248,13 @@ to be done on word values, and don't want to explicitly have to cast everything
long value as an unsigned 32 bits value just fine.
Operations on long integers take a lot of instructions on 8 bit cpu's so code that uses them
a lot will be much slower than when you restrict yourself to 8 or 16 bit values. Use long values sparingly.
**Several operations on long values require the use of the R0 and R1 virtual register as temporary storage**
.. danger::
**longs and R0/R1**:
**Many operations on long values require the use of the R0 and R1 virtual register as temporary storage**
so if you are working with long values, you should assume that the contents of R0 and R1 are destroyed.
**Using R0 or R1 in expressions that work with longs, will probably give a corrupted result, without
a warning of the compiler!** It is strongly advised to *not* use R0/R1 at all when dealing with longs.
Booleans