Don't combine type and size into a single argument; *every* backend
immediately breaks them apart, so it's really just a huge waste of
effort. Additionally, it avoids using short immediates in the
resulting code, which is a bad thing.
OpenWatcom doesn't like 64-bit switch arguments; the change to 64-bit
type arguments caused that to happen in outmacho.c. Hack around it
for now; however, realistically speaking the whole bit stealing thing
is probably a bad idea, especially since virtually all CPUs handle
short immediates better than long ones.
Correct the implementation of %arg and %local.
It's questionable how much they make sense for 64-bit mode; even in
32-bit mode one normally make references off the stack pointer instead
of the base pointer (frame pointer), but that requires keeping track
of the stack pointer offset.
Permit opcode names to be used as labels if and only if they are
succeeded by a colon. Opcode names occurring when parsing expressions
are all treated as labels; a leading colon occurred when parsing an
instruction forces a parser restart with the instruction forcibly
treated as an identifier.
assemble.c was full of code containing ins->oprs[c - 0xxx] where 0xxx
was the base of the particular code block. Verbose and error prone
when code is moved around. Now we precompute opx = &ins->oprs[c & 3]
before dispatching, resulting in less code.
Don't warn for overflow in segmented references; those are linker
references and it is up to the backend or the linker to warn if they
overflow their permitted size.
Use a 32-bit limb size ("like a digit, but bigger") for floating-point
conversion. This cuts the number of multiplications per constant by a
factor of four.
This means supporting fractional-limb-sized numbers, so while we're at
it, add support for 8-bit floating point numbers (apparently used in
graphics and in audio compression applications.)
Fix warning in rdfload.c about cast to pointer of different size when
compiling on 64 bits. Of course, rdfload is probably useless on 64
bits, but it's pretty useless in the first place.
Revamp the address- and prefix-handling code to make more sense in
64-bit mode. We are now a lot closer to where we want to be, but
we're not quite there yet.
ndisasm may very well have problems, or give counterintuitive output.
However, checking it in so we can make forward progress.
Some platforms apparently feel -std=c99, which defines
__STRICT_ANSI__, should also hide a bunch of function prototypes.
This rather sucks. At least try to deal with it.
MinGW and DJGPP both have this problem, in particular.
Correct the handling of floating-point tokens in the preprocessor.
The preprocessor scanner and the main scanner really are painfully
divergent for no good reason.
(pradix && pradix > sradix) etc. is unnecessary since pradix and
sradix cannot be negative, so zero is always the smallest value.
Put in a comment explaining why making the default radix == 10 doesn't
need any additional error checking.
A floating point number starting with 0. 0e or 0E is still decimal.
Make it easier by falling back to the standard decimal conversion
routine for anything not recognized as a radix prefix.
For consistency, support binary and octal floating-point, and accept
a "0d" or "0t" prefix for decimal floating-point. However, we do not
accept a binary exponent (p) for a decimal mantissa, or vice versa.
