James Jones [Mon, 18 Jul 2022 06:20:21 +0000 (23:20 -0700)]
Add NewDebugSymbol(): stabs symbol factory
This function, currently unused, generates a stabs
debugging symbol, as documented here:
https://sourceware.org/gdb/onlinedocs/stabs.html
It can be used to process stabs directives, also
documented at the above URL, generated by HLL
compilers such as GCC, as well as to generate line
number and file name debug symbols when assembling
hand-coded assembly files with the -g option.
v2:
-Don't double-init stabs symbol fields
-Consistently use tabs, not spaces
James Jones [Mon, 13 Jun 2022 03:54:39 +0000 (20:54 -0700)]
Fix pack/unpack instructions
The GPU-specific PACK and UNPACK instructions
share opcode 63. PACK is chosen by encoding '0'
in the source operand, and UNPACK is chosen by
encoding '1' in the source operand. RMAC had the
magic source operand values reversed.
Shamus Hammons [Mon, 27 Jun 2022 13:44:00 +0000 (08:44 -0500)]
Minor fix to kill unnecessary field YPOS in gpuobj in the OP assembler.
Turns out that the documentation we relied on was bogus; SCPCD confirmed
this (from the Jaguar netlists) as well. Thanks to Bastian (42bs) for
the patch! :-)
Shamus Hammons [Mon, 30 May 2022 22:40:19 +0000 (17:40 -0500)]
Fix to prevent defined registers/CCs from being exported in the symtab.
As it turns out, this was not due to malice but because RMAC was set up
to squeeze out every label ever defined in the assembly. Hopefully,
with this patch, things should be a bit more sane. :-)
ggn [Thu, 24 Mar 2022 11:28:09 +0000 (13:28 +0200)]
Fix for #159: Split register sets according to architecture into different tables so they don't clash with label/symbol names. Modified tokeniser to use different tables when scanning for registers
ggn [Mon, 7 Mar 2022 17:49:09 +0000 (19:49 +0200)]
Removed some dead code, as well as all gpu/dsp regbank check code (not only it was complicated, it also was very incomplete - for example: no bank checks were performed during fixups)
ggn [Sun, 6 Mar 2022 18:07:19 +0000 (20:07 +0200)]
.equr overhaul part 1: remove gpu/dsp only restriction, make sure things still work (they do, but exported equrs do not match, which is weird considering they shouldn't be exported in the first place)
Add new optimisation switches for 56001 mode that were missing. Added warnings to all optimisation messages, as well as mention which switch caused the optimisation. Moved opt +op to opt +30 (Issue #185)
James Jones [Thu, 27 Aug 2020 05:46:16 +0000 (22:46 -0700)]
Treat ':' as a path separator on non-Windows platforms
In addition to ';', allow the use of ':' as a path
separator in RMACPATH, the -i parameter, and any
other uses of nthpath. This makes rmac more
consistent with standard Unix tool behavior on
Unix-like systems.
Shamus Hammons [Tue, 8 Jun 2021 03:42:33 +0000 (22:42 -0500)]
Harden RISC register parser and simplify expression evaluator.
The bulk of this patch is ggn's; I rolled a few more macros after I
realized that the EOL check in the RISC assembler required checking its
return value as well as EvaluateRegisterFromTokenStream()'s. :-/
James Jones [Thu, 27 Aug 2020 05:19:26 +0000 (22:19 -0700)]
Fix RMACPATH
Commit 9ecc6f5e49e1740adee78dd45e1115c7e4fcc314
(Fix for bug #167) fixed specifying multiple
include directories on the command line, but in
doing so broke specifying any include directories
via the RMACPATH environment variable. Fix this
by restoring the old behavior of searchpath being
NULL if -i/-I were not specified.
We bumped the # of tokens in the TOKENSTREAM structure from 32 to 64,
but also added some logic to the macro invocation code to check if we
break the limits and thus don't crash. Will 64 be enough? My crystal
ball is cloudy ATM... :-P
James Jones [Sun, 12 Apr 2020 05:25:48 +0000 (22:25 -0700)]
Properly advance past register bank specifier
Register banks, like all constants, are stored
in the token stream as uint64_t values. Hence,
to advance the stream, the 32-bit tok pointer
must be advanced twice after parsing a register
bank.
Shamus Hammons [Wed, 15 Jan 2020 04:14:01 +0000 (22:14 -0600)]
Fixes for bug #144 (unitialized code paths in 6502 codegen).
I was able to throw away a bunch of code in m6502cg(); things should be
much clearer vis-a-vis how things are parsed and code flow through that
function. Plus it's always nice to be able to throw away code. :-)
Now at v2.0.9.