Re: [Tack-devel] Trying 8-byte integers

[George K. <ke...@gm...>]

On Tue, 3 Sep 2019 21:41:10 +0200
David Given <dg...@co...> wrote:

> Remember that you'll also need to change the definition of arith to be a
> int64_t; this is used (mostly) everywhere for intermediate value
> representation. That change should be largely orthogonal to the code
> generation side of things but is probably going to be really fiddly and
> error prone, as I'm sure there's lots of code which turn ariths into ints
> and back (quite possibly written by me; the old code is probably pretty
> good about this due to needing to support 16-bit ints).

It seemed too difficult to change arith to a different type.  Some
code assumes that arith is long, and long has exactly 4 bytes.

I instead added a second type, writh (wide arithmetic), and changed
some variables in cemcom.ansi from arith to writh.  Because writh is
private to cemcom.ansi, it doesn't break assumptions in other modules
or tools.  It does add several conversions from writh to arith, and
there is a risk that such conversions may go bad.

EM compact assembly can't encode an 8-byte constant for _ldc_ (load
double-word constant).  EM defines sp_cst8, but ACK has no way to
encode or decode sp_cst8 values.  To work around this, I modified
cemcom.ansi to avoid _ldc_ with constants wider than 4 bytes.  I use
_rom_ and _con_, like `con 123I8`, because EM encodes rom and con
values as strings.

I am adding a new test set in tests/plat/long-long for long long
operations in C.  Now it tests addition, subtraction, comparison,
and left/right shift on linux386.  After I have more tests, I might
add long long to another platform, perhaps linux68k.

-- 
George Koehler <ke...@gm...>