8-byte long long in ACK C for i386, m68020 #208
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This takes literal integers, not expressions, because each machine defines its own valu_t for expressions, but valu_t can be too narrow for an 8-byte integer, and I don't want to change all the machines to use a wider valu_t. Instead, change how the assembler parses literal integers. Remove the NUMBER token and add a NUMBER8 token for an int64_t. The new .data8 pseudo emits all 8 bytes of the int64_t; expressions narrow the int64_t to a valu_t. Don't add any checks for integer overflow; expressions and .data* pseudos continue to ignore overflow when a number is too wide. This commit requires int64_t and uint64_t in the C compiler to build the assembler. The ACK's own C compiler doesn't have these. For the assembler's temporary file, add NUMBER4 to store 4-byte integers. NUMBER4 acts like NUMBER[0-3] and only stores a non-negative integer. Each negative integer now takes 8 bytes (up from 4) in the temporary file. Move the `\fI` and `\fP` in the uni_ass(6) manual, so the square brackets in `thing [, thing]*` are not italic. This looks nicer in my terminal, where italic text is underlined.
This turns EM `con 5000000000I8` into assembly `.data8 5000000000` for machines i386, i80, i86, m68020, powerpc, vc4. These are the only ncg machines in our build. i80 and i86 get con_mult(sz) for sz == 4 and sz == 8. The other machines only get sz == 8, because they have 4-byte words, and ncg only calls con_mult(sz) when sz is greater than the word size. The tab "\t" after .data4 or .data8 is like the tabs in the con_*() macros of mach/*/ncg/mach.h. i86 now uses .data4, like i80. Also, i86 and i386 now use the numeric string without converting it to an integer and back to a string.
This provides adi, sbi, mli, dvi, rmi, ngi, dvu, rmu 8, but is missing
shifts and rotates. It is also missing conversions between 8-byte
integers and other sizes of integers or floats. The code might not be
all correct, but works at least some of the time.
I adapted this from how ncg i86 does 4-byte integers, but I use a
different algorithm when dividing by a large value: i86 avoids the div
instruction and uses a shift-and-subtract loop; but I use the div
instruction to estimate a quotient, which is more like how big integer
libraries do division. My .dvi8 and .dvu8 also set ecx:ebx to the
remainder; this might be a bad idea, because it requires .dvi8 and
.dvu8 to always calculate the remainder, even when the caller only
wants the quotient.
To play with 8-byte integers, I wrote EM procedures like
mes 2, 4, 4
exp $ngi
pro $ngi,0
ldl 4
ngi 8
lol 0
sti 8
lol 0
ret 4
end
exp $adi
pro $adi,0
ldl 4
ldl 12
adi 8
lol 0
sti 8
lol 0
ret 4
end
and called them from C like
typedef struct { int l; int h; } q;
q ngi(q);
q adi(q, q);
Add long long type, but without literals; you can't say '123LL' yet.
You can try constant operations, like `(long long)123 + 1`, but the
compiler's `arith` type might not be wide enough. Conversions,
shifts, and some other operations don't work in i386 ncg; I am using a
union instead of conversions:
union q {
long long ll;
unsigned long long ull;
int i[2];
};
Hack plat/linux386/descr to enable long long (size 8, alignment 4)
only for this platform. The default for other platforms is to disable
long long (size -1).
In lang/cem/cemcom.ansi,
- BigPars, SmallPars: Add default size, alignment of long long.
- align.h: Add lnglng_align.
- arith.c: Convert arithmetic operands to long long or unsigned long
long when necessary; avoid conversion from long long to long.
Allow long long as an arithmetic, integral, or logical operand.
- ch3.c: Handle long long like int and long when erroneously applying
a selector, like `long long ll; ll.member` or `ll->member`. Add
long long to integral and arithmetic types.
- code.c: Add long long to type stabs for debugging.
- conversion.c: Add long long to integral conversions.
- cstoper.c: Write masks up to full_mask[8]. Add FIXME comment.
- declar.g: Parse `long long` in code.
- decspecs.c: Understand long long in type declarations.
- eval.c: Add long long to operations, to generate code like `adi 8`.
Don't use `ldc` with constant over 4 bytes.
- ival.g: Allow long long in initializations.
- main.c: Set lnglng_type and related values.
- options.c: Add option like `-Vq8.4` to set long long to size 8,
alignment 4. I chose 'q', because Perl's pack and Ruby's
Array#pack use 'q' for 64-bit or long long values; it might be a
reference to BSD's old quad_t alias for long long.
- sizes.h: Add lnglng_size.
- stab.c: Allow long long when writing the type stab for debugging.
Switch from calculating the ranges to hardcoding them in strings;
add 8-byte ranges as a special case. This also hardcodes the
unsigned 4-byte range as "0;-1". Before it was either "0;-1" or
"0;4294967295", depending on sizeof(long) in the compiler.
- struct.c: Try long long bitfield, but it will probably give the
error, "bit field type long long does not fit in a word".
- switch.c: Update comment.
- tokenname.c: Define LNGLNG (long long) like LNGDBL (long double).
- type.c, type.str: Add lnglng_type and ulnglng_type. Add function
no_long_long() to check if long long is disabled.
For now, a long long literal must have the 'LL' or 'll' suffix. A
literal without 'LL' or 'll' acts as before: it may become unsigned
long but not long long. (For targets where int and long have the same
size, some literals change from unsigned int to unsigned long.)
Type `arith` may be too narrow for long long values. Add a second
type `writh` for wide arithmetic, and change some variables from arith
to writh. This may cause bugs if I forget to use writh, or if a
conversion from writh to arith overflows. I mark some conversions
with (arith) or (writh) casts.
- BigPars, SmallPars: Remove SPECIAL_ARITHMETICS. This feature
would change arith to a different type, but can't work, because it
would conflict with definitions of arith in both <em_arith.h> and
<flt_arith.h>.
- LLlex.c: Understand 'LL' or 'll' suffix. Cut size of constant when
it overflows writh, not only when it overflows the target machine's
types. (This cut might not be necessary, because we might cut it
again later.) When picking signed long or unsigned long, check the
target's long type, not the compiler's arith type; the old check
for `val >= 0` was broken where sizeof(arith) > 4.
- LLlex.h: Change struct token's tok_ival to writh, so it can hold a
long long literal.
- arith.c: Adjust to VL_VALUE being writh. Don't convert between
float and integer at compile-time if the integer might be too wide
for <flt_arith.h>. Add writh2str(), because writh might be too
wide for long2str().
- arith.h: Remove SPECIAL_ARITHMETICS. Declare full_mask[] here,
not in several *.c files. Declare writh2str().
- ch3.c, ch3bin.c, ch3mon.c, declarator.c, statement.g: Remove
obsolete casts. Adjust to VL_VALUE being writh.
- conversion.c, stab.c: Don't declare full_mask[].
- cstoper.c: Use writh for constant operations on VL_VALUE, and for
full_mask[].
- declar., field.c, ival.g: Add casts.
- dumpidf.c: Need to #include "parameters.h" before checking DEBUG.
Use writh2str, because "%ld" might not work.
- eval.c, eval.h: Add casts. Use writh when writing a wide constant
in EM.
- expr.c: Add and remove casts. In fill_int_expr(), make expression
from long long literal. In chk_cst_expr(), allow long long as
constant expression, so the compiler may accept `case 123LL:` in a
switch statement.
- expr.str: Change struct value's vl_value and struct expr's VL_VALUE
to writh, so an expression may have a long long value at compile
time.
- statement.g: Remove obsolete casts.
- switch.c, switch.str: Use writh in case entries for switch
statements, so `switch (ll) {...}` with long long ll works.
- tokenname.c: Add ULNGLNG so LLlex.c can use it for literals.
Skip the long-long test set on other platforms, because they don't have long long. Each platform would need to implement 8-byte operations like `adi 8` in its code generator, and set long long to 8 bytes in its descr file. The first test is for negation, addition, and subtraction. It also requires comparison for equality.
Add tests for comparisons and shifts. Also add enough integer conversions to compile the shift test (llshift_e.c), and disable some wrong rules for ldc and conversions.
Also change EM_PSIZE to _EM_PSIZE. I will add _EM_LLSIZE to this test, then all 3 macros will have the leading underscore.
Also change UINT32_MAX in <stdint.h> from 4294967295 to 4294967295U.
The U suffix avoids a promotion to long or unsigned long if it would
fit in unsigned int.
Define _EM_LLSIZE but not EM_LLSIZE. The leading underscore is a
convention for such macros. If code always uses _EM_LLSIZE, we will
never need to add EM_LLSIZE. The flag -D_EM_LLSIZE={q} is in
plat/linux386/descr, not lib/descr/fe, so platforms without long long
don't define _EM_LLSIZE.
<stdint.h> doesn't keep the old code for _EM_LSIZE == 8, because I
change it to _EM_LLSIZE == 8. No platform had _EM_LSIZE == 8, and the
old limits like INT64_MAX were wrong.
These tests are in core/rotate_e.e with the other rotation tests, and only run on platforms where _EM_LLSIZE == 8.
My i386 code from 893df4b gave the wrong sign to some 8-byte remainders. Fix by splitting .dvi8 and .rmi8 so each has its own code to pick the sign. They and .dvu8 and .rmu8 share a private sub .divrem8 for unsigned division. Improve the i386 code by using instructions like _bsr_ and _shrd_. Change the helpers to yield a quotient in ebx:eax or a remainder in ecx:edx; this seems more convenient, because _div_ puts its quotient in eax and remainder in edx.
Given `long long o1` and `unsigned int o2`, then `o1 << o2` was converting o2 to long long and then to int. Remove the first conversion and just convert o2 to int.
Add cases with long long a, b in hexadecimal, where it is more obvious whether or not a + b or a - b carries to or borrows from bit 32. Add failure codes to identify each case.
Add EXACT to the rule for adi 8, in the same way that the old rules for and 8, ior 8, xor 8 have EXACT. Add rules for sli 8 and sru 8 when shifting 32 bits, and add assertions in llshift_e.c to test these rules.
The assembler wrongly defined _bfexts_ and _bfffo_ with the same bits as _bfextu_; this turned all bfexts and bfffo instructions into bfextu. Motorola's 68k Programmer's Reference Manual (1992) gives different bits for bfexts, but still has wrong bits for bfffo. Change bfexts and bfffo to match the 68k emulators musahi, aranym, syn68k. The bitfield width is from 1 to 32, not 0 to 31, so move the warning from 32 to 0. This doesn't change the warning message, so it will say that 0 is "too big", when 0 is really too small.
Add rules for 8-byte integers to m68020 ncg. Add 8-byte long long to ACK C on linux68k. Enable long-long tests for linux68k. The tests pass in our emulator using musahi; I don't have a real 68k processor and haven't tried other emulators. Still missing are conversions between 8-byte integers and any size of floats. The long-long tests don't cover these conversions, and our emulator can't do floating-point. Our build always enables TBL68020 and uses word size 4. Without TBL68020, 8-byte multiply and divide are missing. With word size 2, some conversions between 2-byte and 8-byte integers are missing. Fix .cii in libem, which didn't work when converting from 1-byte or 2-byte integers. Now .cii and .cuu work, but also add some rules to skip .cii and .cuu when converting 8-byte integers. The new rule for loc 4 loc 8 cii `with test_set4` exposes a bug: the table may believe that the condition codes test a 4-byte register when they only test a word or byte, and this incorrect test may describe an unsigned word or byte as negative. Another rule `with exact test_set1+test_set2` works around the bug by ignoring the negative flag, because a zero-extended word or byte is never negative. The old rules for comparison and logic do work with 8-byte integers and bitsets, but add some specific 8-byte rules to skip libem calls or loops. There were no rules for 8-byte arithmetic, shift, or rotate; so add some. There is a register shortage, because the table requires preserving d3 to d7, leaving only 3 data registers (d0, d1, d2) for 8-byte operations. Because of the shortage, the code may move data to an address register, or read a memory location more than once. The multiplication and division code are translations of the i386 code. They pass the tests, but might not give the best performance on a real 68k processor.
Shifts that drop an EM word don't need to coerce the word to REG. Some arithmetic right shifts can use _cdq_. Drop rules for illegal integer conversions. Sizes below a word are illegal in EM, except as the source size of _cii_.
This allows `long long x; switch (x) {...}` in C. Add test in C.
This adapts the code for csa 8 and csb 8 from the existing code for
csa 4 and csb 4, for both i386 and m68020.
davidgiven
reviewed
Sep 30, 2019
lang/cem/libcc.ansi/headers/stdint.h
Outdated
|
|
||
| /* We only get int64_t if longs are 8 bytes. */ | ||
| /* We only get int64_t if long longs are 8 bytes. */ |
There was a problem hiding this comment.
We should probably keep the _EM_LSIZE == 8 case here for LP64 architectures which use 64 bit longs and long longs.
davidgiven
reviewed
Sep 30, 2019
mach/proto/as/comm2.y
Outdated
| @@ -22,6 +22,7 @@ static item_t *last_it, *o_it; | |||
| %union { | |||
| word_t y_word; | |||
| valu_t y_valu; | |||
| int64_t y_valu8; | |||
There was a problem hiding this comment.
Is it worth having two different members here, or should we just define valu_t to an int64? (I can imagine problems if something writes a y_valu8 but reads a y_valu by mistake, which wouldn't be visible on little-endian machines.)
There was a problem hiding this comment.
valu_t gets redefined in mach/{arm, i386, i86, m68020, m68k2, mips, ns, powerpc, vax4, vc8, z8000}/as/mach0.c. Maybe we can remove those redefinitions and just let proto/as/comm0.h define valu_t as int64_t, but I haven't tried it yet.
|
Thank you very much for this! I left a couple of small comments but I didn't spot any obvious issues. My only concern is that there's a lot of scope for subtle, hard-to-find breakage in cemcom.ansi due to e.g. erroneously casting a writh to an arith and losing the top 32 bits, but this kind of problem isn't new and we should go ahead anyway. I've filed #209 because we really, really should have a proper test suite for this. |
Most machines had undefined valu_t and redefined it to a different type. Edit mach/*/as/mach0.c to remove such redefinitions, so the next change to valu_t will affect all machines. Edit mach/proto/as/comm0.h to change valu_t to int64_t, and add uvalu_t and uint64_t. Remove int64_t y_valu8 from the yacc %union, now that valu_t y_valu can hold 64 bits. Replace y_valu8 with y_valu. The .data8 pseudo becomes less special; it now accepts absolute expressions. This change simplifies the assembler and seems to have no effect on the assembled output. Among the files in share/ack/examples, the only changes are in hilo_bas.* and startrek_c.linuxppc, but those files seem to change whenever I rebuild them.
This will cause ACK libc to provide int64_t as long (instead of long long) on LP64, if we ever get such a platform. LP64 would have 64-bit long and 64-bit long long, so int64_t might be either type. For example on amd64, int64_t is long in NetBSD libc, and long long in OpenBSD libc. Support for long long in ACK remains incomplete (no printf "%lld"), so it seems better to prefer long where possible. Also, int64_t being long before long long is more consistent with int32_t being int before long. Put suffixes on the values of INT32_MAX, INT64_MAX, and related constants, so they have the same types as int32_t and int64_t.
|
After reading your comments, I added 2 more commits to change assembler's valu_t to int64_t and add back _EM_LSIZE == 8 to <stdint.h>. In my commit message for a434749, I mentioned startrek_c.linuxppc by mistake. It should be startrek_c.linuxmips. I'm too lazy to edit the message. |
|
LGTM. Thank you very much! |
davidgiven
added a commit
that referenced
this pull request
Nov 23, 2019
8-byte long long in ACK C for i386, m68020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch adds the type
long longto ACK C, which is an 8-byte integer on i386 and m68020, and causes an error on other machines. A new test set in tests/plat/long-long operates on 8-byte integers on i386 and m68020. Beware that not everything works:I don't provide conversions between long long and floating-point types. Such a conversion might cause an error from ncg, or it might emit code that corrupts the stack.
446020022096LLworks, but446020022096gets cut to an unsigned long. ACK C still follows C89, not C99, for literals without the LL suffix. C89 had no long long. C99 would use long long if the literal can't fit in long.libc has almost no support for 8-byte integers. For example,
printf("%lld", x)doesn't work. I provide int64_t and uint64_t in <stdint.h>, but almost nothing else.ACK languages had no 64-bit integers until now. My mail to tack-devel gave a few reasons to want 8-byte integers. Parts of the ACK assume that integers are never wider than 4 bytes, so I work around this assumption.
.data8to the assembler..data8only takes a literal integer, not an expression, because expressions still use a machine-dependent integer type that might have only 4 bytes..data8when they encounter an 8-byte constant.adi 8. The C compiler uses a new type writh (wide arithmetic) for constant operations, to avoid changing the old type arith.adi 8to i386 ncg, or tests in C; butrol 8andror 8have tests in EM. Before these changes in 2019, the last change to mach/i386/ncg/table was in 1995.adi 8to m68020 ncg.EM compact assembly can't encode an 8-byte constant for ldc (because the implementation of
sp_cst8is missing), so I modified the C compiler to avoid ldc with constants wider than 4 bytes. This diverts 8-byte constants to rom (where EM encodes them as strings) and causes slower code. For example, the C codebecomes the i386 code
instead of the simpler
To implement
sp_cst8and enable ldc, one would need to widen the type arith from long to int64_t. This is difficult, because parts of the ACK assume that arith is always long. This branch keeps arith as long.To convert between long long and floating-point types, one would need to change the interface to our mach/proto/fp software floating-point, which now assumes that integers have at most 4 bytes. This also affects i386, because its 8087 library has the same interface. For m68020, I use the ack's emulator, which is missing floating-point (but a newer version of musahi might have floating-point).