Makes it a lot easier to find out what's going on with interrupt lines
if the ports have tracing output.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We need the DIR bit cleared, not set, in order for the pin to be treated
as an input.
When looking up the data value, we need to shift the "level" value over by
"my_port" rather than "bit" as the latter has already been shifted over.
We also should normalize the "level" coming in from the outside worlds to
the set of {0,1} since those are the only values that matter to GPIOs.
We need the BOTH bit set, not cleared, in order for the pin to trigger
on both edges.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The clear/set/toggle MMRs aren't backed by "real" data; they implicitly
perform bit operations on the associated data register. So when we go
to process writes to them, we need to adjust the pointer accordingly so
that the actual backing data is modified.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When I originally wrote the w1c helper funcs, I used it in a few places.
Then I forgot how it worked and when I later documented it, I described
the 3rd arg in the exact opposite way it is actually used. This error
propagated to a bunch of devices registers that were not explicitly
tested (a bunch of the devices are stubs which merely exist to say "no
device is connected" to make device drivers happy).
So once the documentation is unscrewed, fix all of the broken call sites.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We'll need these bits in an upcoming patch, so map out the whole
LSR MMR now.
Fix up indentation style while we're here.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Blackfin PRM says that the top 8 bits of the accumulator must be
cleared when using the VIT_MAX insn, so the sim has followed this spec.
Matching the hardware behavior though when the high bits are not cleared
is easy to do and doesn't break existing behavior, so go for it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Blackfin PRM does not cover this case, but the hardware is clear: even
if the search criteria is not met (and thus a new 16bit value is loaded up
into the accumulator), the accumulator undergoes 16bit sign extension. So
simply reload the low signed 16bits in that case.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Acc=-Acc insn can overflow or carry with edge values, so make sure
we update the ASTAT bits accordingly to match the hardware. Also fix
a thinko where we always updated AC0 even when working with A1 regs.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When encoding the SIC/pin info into unique input port ids, I used bases
of 100 when I meant to use 0x100. Rather than simply fix the decoding
math in the different functions, create a few helper macros to simplify
the SIC/pin encoding and decoding steps. This makes the resulting tables
nice & clear.
And now that pins are clear, the 533 and 537 port_event handlers may
easily be merged into one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The hardware allows the byteop[123]p insns to use the same src reg pair,
so remove the combination check in the sim.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The bus addresses have to be valid numbers, so 'g' and 'h' won't work.
Oddly, the common code silently ignored this which is why I didn't notice
in the first place.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
do not invoke the host's functionality directly. Invoke
sim_io_stat() instead of stat() for implementing TARGET_SYS_stat.
Implement TARGET_SYS_fstat, TARGET_SYS_rename, and TARGET_SYS_unlink.
We weren't updating AZ when doing a 16bit add or sub insn. Implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
No point in moving unchanged acc values to the acc regs, and avoid
updating the acc ASTAT bits when only reading. This fixes incorrect
changing of the ASTAT bits when they're only being read.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current dsp mult handler does not take care of overflows which turn
values negative (and thus set AN in ASTAT). So implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current dsp mult handler does not take care of overflows and updating
the V ASTAT bit. So implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When testing ASTAT regs, specific bit differences carry a lot more meaning
than when checking the value of a data register. So automatically decode
the bits of the two values and print things out so that people don't have
to manually do it themselves every time.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The saturation behavior with fract modes differs from non-fract modes.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This can boot Das U-Boot and a Linux kernel. It also supports Linux
userspace FLAT and FDPIC (dynamic and static) ELFs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim keeps track of which allocations are zero-ed internally (via
zalloc) and then calls a helper "zfree" function rather than "free".
But this "zfree" function simply calls "free" itself. Since I can
see no point in this and it is simply useless overhead, punt it.
The only real change is in hw-alloc.c where we remove the zalloc_p
tracking, and sim-utils.c where zfree is delete. The rest of the
changes are a simple `sed` from "zfree" to "free".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim-events code jumps through some hoops to avoid using 64bit math
to manage the current time. One fundamental assumption here is that by
constantly scheduling the sim poll event a short time into the future,
the 64bit difference will always fall into a signed 32bit value. This
does work most of the time, except for when processing the sim poll event
itself.
Normally, sim_events_process() will dequeue the sim poll event, update
the current time (time_from_event) according to the next pending event,
process the sim poll event (which will then requeue the sim poll event),
and then continue on.
The problem here of course is that the current time is updated in that
small window before the sim poll event gets a chance to reschedule itself.
So if the 64bit difference between the current time and the next event
does not fit into the signed 32bit value, time_from_event overflows, and
the internal assert at the end of update_time_from_event() triggers.
Since attempts at tweaking sim_events_process() logic introduced other
subtle bugs (due to tangled assumptions between most pieces of the sim
time keeping code), change the time_from_event to a real 64bit value.
Tests on my system between a 32bit ELF and a 64bit ELF show no practical
difference (it's all lost in the system noise). Basically, I booted a
Linux kernel to userspace and then paniced it; this gave me a constant
sample size of about 18 million insns.
This was noticed when simulating Blackfin Das U-Boot. The simulated core
timer is given the max unsigned timeout value possible on a 32bit processor
(0xffffffff). This timeout value is used directly to schedule a hw event
in the sim future (the IRQ firing). Once the sim poll event is kicked off,
the next pending event is the core timer event which is more than 2^31
ticks in the future, and the sim aborts with:
sim-events.c:435: assertion failed - current_time == sim_events_time (sd)
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I can't find any history for why the call to hw_tree_delete is commented
out, and the VCS history shows that this goes back to the original import
in 2009. I did find some vague reference to it from 2000 (pretty close
to the original import of code), but no actual details.
Without this call, every new instance of the sim results in all old
previously allocated resources being leaked. With some devices, this
isn't just memory, it's things like open file descriptors or mmaps.
So if there are pending issues with this, I'd rather we get the sims
sorted out rather than continuing to leak this stuff. Especially since
the "let's wait for the sims to fix themselves" hasn't actually happened
in the last 10+ years.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I find it annoying when using --memory-mapfile that I also need to look
up and manually specify the file size to the following --memory-region
option. So make a length of 0 in the following --memory-region trigger
an auto-sizing of the map to the length of the file being mapped.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
gdb/ChangeLog
* remote-sim.c (gdbsim_store_register): Update API to
sim_store_register to check more error conditions.
include/gdb/ChangeLog
* remote-sim.h (sim_store_register): Update the API
documentation for this function.
sim/erc32/ChangeLog
sim/h8300/ChangeLog
sim/m32c/ChangeLog
sim/mn10300/ChangeLog
sim/ppc/ChangeLog
sim/rx/ChangeLog
sim/v850/ChangeLog
* ???.c (sim_store_register): Update return value to
match new API.
The 2nd arg to SIM_AC_OPTION_HARDWARE is described as "a space separated
list of devices that override the defaults" while the 3rd arg is "a space
separated list of extra target specific devices". But the macro doesn't
seem to treat the 2nd arg this way.
Instead, it will always add the default list of devices, and only add the
extra target specific devices if the 2nd arg is not specified. So rework
the logic slightly to handle the 2nd arg as documented.
This shouldn't affect any targets in the tree as no one passes in a non-
empty value as the 2nd arg.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These functions either call abort() themselves, or call functions which
are already marked noreturn. Either way, they don't return, so mark them
as such so calling code can assume this. This fixes some uninitialized
warnings due to code paths that end in an abort function.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim_load_file func creates a buffer with arbitrary data in it (reads
it via the bfd). It then passes it on to a sim_write_fn which expects a
unsigned char buffer. Since sim_load_file itself doesn't care about the
contents, tweak the type to avoid signed mismatch warnings from gcc:
common/sim-load.c: In function ‘sim_load_file’:
common/sim-load.c:143: warning: pointer targets in passing argument 3 of ‘do_write’ differ in signedness
common/sim-load.c:143: note: expected ‘const unsigned char *’ but argument is of type ‘char *’
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We have malloc (uninitialized buffer), zalloc (zeroed buffer), and
nzalloc (zeroed array). But we don't have a way to allocate an
uninitialized array. Add a HW_NALLOC to fill this gap.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The HW_NZALLOC macro has all caps args for some reason (unlike the other
alloc helpers), and ends up not using the "ME" argument since its copy
and paste source uses "me". Make all the args lowercase to match the
style of all the other args and make it use the correct "me".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
There are options for listing the current device/hw tree and memory
regions, but no way to find out at run time all the current mappings.
So add a new --map-info option akin to the --memory-info option which
displays all the current mappings.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When the sim is configured with profile support disabled, the build fails:
./../common/sim-profile.c: In function 'profile_option_handler':
./../common/sim-profile.c:337:6: warning: implicit declaration of function 'PROFILE_PC_FREQ'
./../common/sim-profile.c:337:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:351:6: warning: implicit declaration of function 'PROFILE_PC_NR_BUCKETS'
./../common/sim-profile.c:351:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:381:6: warning: implicit declaration of function 'PROFILE_PC_SHIFT'
./../common/sim-profile.c:381:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:405:8: warning: implicit declaration of function 'PROFILE_PC_START'
./../common/sim-profile.c:405:8: error: lvalue required as left operand of assignment
./../common/sim-profile.c:406:8: warning: implicit declaration of function 'PROFILE_PC_END'
./../common/sim-profile.c:406:8: error: lvalue required as left operand of assignment
./../common/sim-profile.c: In function 'profile_uninstall':
./../common/sim-profile.c:1299:7: warning: implicit declaration of function 'PROFILE_INSN_COUNT'
./../common/sim-profile.c:1299:37: warning: comparison between pointer and integer
./../common/sim-profile.c:1300:2: warning: passing argument 1 of 'zfree' makes pointer from integer without a cast
../common/sim-utils.h:30:6: note: expected 'void *' but argument is of type 'int'
make[2]: *** [sim-profile.o] Error 1
So add some stubs similar to how some of the other subsystems are
stubbed out so things build correctly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When building with device and hw support, the sim-core code generates a
lot of build time warnings such as:
./../common/sim-core.c: In function 'sim_core_map_attach':
./../common/sim-core.c:198:7: warning: passing argument 1 of 'device_error' from incompatible pointer type
../common/sim-core.h:347:6: note: expected 'struct device *' but argument is of type 'struct hw *'
./../common/sim-core.c:235:7: warning: passing argument 1 of 'device_error' from incompatible pointer type
../common/sim-core.h:347:6: note: expected 'struct device *' but argument is of type 'struct hw *'
In reality, these two structures get cast back and forth in the core
code already and so are "compatible". So tweak the three functions
that generate all of these warnings to include the casts automatically.
I know this isn't exactly clean, but the current device/hw ifdef
approach is full of landmines itself and I'm not entirely sure how
to unscrew it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Rather than having to bang out chunks of data one byte at a time over
the socket interface, add a write variant that accepts an arbitrarily
long buffer. This speeds things up considerably when we have many
chars to send out at once.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* rx.h (RX_Operand_Type): Add TwoReg.
(RX_Opcode_ID): Remove ediv and ediv2.
[opcodes]
* rx-decode.opc (SRR): New.
(rx_decode_opcode): Use it for movbi and movbir. Decode NOP2 (mov
r0,r0) and NOP3 (max r0,r0) special cases.
* rx-decode.c: Regenerate.
[sim/rx]
* rx.c (decode_cache_base): New.
(id_names): Remove ediv and edivu.
(optype_names): Add TwoReg.
(maybe_get_mem_page): New.
(rx_get_byte): Call it.
(get_op): Add TwoReg support.
(put_op): Likewise.
(PD, PS, PS2, GD, GS, GS2, DSZ, SSZ, S2SZ, US1, US2, OM): "opcode"
is a pointer now.
(DO_RETURN): New. We use longjmp to return an exception result.
(decode_opcode): Make opcode a pointer to the decode cache. Save
decoded opcode information and re-use. Call DO_RETURN instead of
return throughout. Remove ediv and edivu.
* mem.c (ptdc): New. Adds decode cache.
(rx_mem_ptr): Support it.
(rx_mem_decode_cache): New.
* mem.h (enum mem_ptr_action): add MPA_DECODE_CACHE.
(rx_mem_decode_cache): Declare.
* gdb-if.c (sim_resume): Add decode_opcode's setjmp logic here...
* main.c (main): ...and here. Use a fast loop if neither trace
nor disassemble is given.
* cpu.h (RX_MAKE_STEPPED, RX_MAKE_HIT_BREAK, RX_MAKE_EXITED,
RX_MAKE_STOPPED, RX_EXITED, RX_STOPPED): Adjust so that 0 is not a
valid code for anything.
gdb/
* ser-tcp.c (net_open): Check error return from socket() call by its
equality to -1 not by it being negative.
(net_close): Likewise.
gdb/gdbserver/
* gdbreplay.c (remote_open): Check error return from socket() call by
its equality to -1 not by it being negative.
* remote-utils.c (remote_open): Likewise.
sim/arm/
* communicate.c (MYread_char): Check error return from accept() call
by its equality to -1 not by it being negative.
(MYread_charwait): Likewise.
* main.c (main): Likewise for both socket() and accept() calls.
sim/common/
* dv-sockser.c (dv_sockser_init): Check error return from socket()
call by its equality to -1 not by it being negative.
(connected_p): Likewise for accept() call.
sim/cris/
* dv-rv.c (hw_rv_init_socket): Check error return from socket() call
by its equality to -1 not by it being negative.
(hw_rv_write): Likewise.
(hw_rv_handle_incoming): Likewise.
(hw_rv_poll_once): Likewise.
* rvdummy.c (setupsocket): Likewise.
(main): Likewise for accept() call as returned from setupsocket().
sim/m32c/
* main.c (setup_tcp_console): Check error return from socket() call
by its equality to -1 not by it being negative.
* erc32.c (sis_memory_write): Change prototype to const unsigned char *.
* func.c (exec_cmd, event, advance_time, wait_for_irq): Use uint64
for counts.
* interf.c (run_sim): Change icount to uint64_t. Use strtol directly.
(sim_resume): Specify maximum run time as uint64.
* sis.c (run_sim): Change icount to uint64_t.
* sis.h: Define uint64 as uint64_t. Change various fields and
prototypes to uint64 to support longer simulations.
The testsuite subdir has a note about unifying the target->subdir logic,
so do just that. The end goal here is to have `make check` work out of
the box without having to delve into dejagnu internals.
The target-specific logic is split out of the top level configure.ac file
and into a dedicated configure.tgt similar to other subprojects (gdb and
ld and etc...) with the difference that this file has to be included at
the m4 level instead of the shell level. This is necessary only because
autoconf requires AC_CONFIG_SUBDIRS be given a string literal and not a
variable value.
Then the toplevel and the testsuite configure files pull this in, the sim
subdir gets expanded into testsuite/site.exp, and the default sim run code
uses this info to set the sim path to the local compiled run file if it
hasn't already been specified.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current fpu code with externals enabled results in the warnings:
common/sim-fpu.c:2437: warning: missing initializer
common/sim-fpu.c:2437: warning: (near initialization for 'sim_fpu_zero.sign')
common/sim-fpu.c:2440: warning: missing initializer
common/sim-fpu.c:2440: warning: (near initialization for 'sim_fpu_qnan.sign')
So tweak the old style initializers to avoid these.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The common/ code uses sim_cpu rather than SIM_CPU to avoid inter-header
dependency issues, so follow convention to fix building some targets.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The profile code already has options and handling for accepting a file to
write the profile output like the trace code, but it doesn't actually use
it. At the moment, it simply opens the file at the start and closes it at
the end. So add two new local functions the way the trace code is doing
it and have them figure out whether to write the output to stdout or the
specified file. Then convert all existing output in the profile code to
use these helpers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
There is an architecture-info flag for listing possible arch values, but
there is on equivalent for listing possible model values. So add the
equivalent for models.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
As pointed out by Sandra Loosemore, a bunch of targets define sim_write
themselves instead of using the common/ code. So constify them too.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
A few ports rely on internal dv-sockser state in order to detect whether
a connection has been made (look for 'extern sockser_addr'). Rather than
continuing that tradition, extend the existing status function to return
the socket connection status.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Most the sim write functions declare their source buffer const because
they only ever read from it. The global sim_write() function does not
follow this convention though which causes some warnings when trying to
pass it const strings or buffers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I found the documentation lacking in many places, so I tried filling in a
lot of holes that I personally fell into.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The profile code has a lot of helper macros already, but none yet for the
branch profiling code. So add ones for the basic functions -- taken and
untaken branches.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim code has a lot of static initializer for options and devices, but
since they aren't using newer struct style, they have to specify a value
for every option otherwise gcc spits a lot of warnings about "missing
initializer". So add NULL/0 stubs for pointers/values.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The dup_arg_p function is only given const strings, and it maintains a
local table of those const strings. So constify the whole thing to fix
the GCC warnings:
common/sim-options.c: In function 'sim_parse_args':
common/sim-options.c:559: warning: passing argument 1 of 'dup_arg_p'
discards qualifiers from pointer target type
common/sim-options.c: In function 'print_help':
common/sim-options.c:675: warning: passing argument 1 of 'dup_arg_p'
discards qualifiers from pointer target type
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I've committed the following patch as obvious. The local "prefix"
variable is only assigned const strings, and only passed to printf()
functions, so add "const" to avoid gcc warnings:
common/sim-fpu.c: In function 'sim_fpu_print_status':
common/sim-fpu.c:2508: warning: initialization discards qualifiers
from pointer target type
common/sim-fpu.c:2566: warning: assignment discards qualifiers
from pointer target type
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The local save_data() function takes a pointer to a buffer and only uses it as
the source to the memcpy() function. Since it is given const strings, GCC
likes to spit out warnings:
common/sim-trace.c: In function 'trace_prefix':
common/sim-trace.c:697: warning: passing argument 5 of 'save_data' discards
qualifiers from pointer target type
So I've committed this as obvious.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim-options code assigns a const string to "char *" in decoding the
current environment settings, and only uses it to pass to a printf. GCC
outputs the warnings:
common/sim-options.c: In function 'standard_option_handler':
common/sim-options.c:271: warning: assignment discards qualifiers from pointer
target type
common/sim-options.c:272: warning: assignment discards qualifiers from pointer
target type
common/sim-options.c:273: warning: assignment discards qualifiers from pointer
target type
So I've committed this as "obvious".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The accept() function takes a socklen_t, not an int. Using an int causes:
dv-sockser.c: In function 'connected_p':
dv-sockser.c:273: warning: pointer targets in passing argument 3
of 'accept' differ in signedness
So use the same socklen_t detection code as gdb and convert the accept().
This is the normal "passing a buffer straight to printf makes GCC warn".
While we know this particular case is fine, the trend in this source tree
is to fix this anyways to avoid the warnings.
GCC issues warnings because const strings like "foo" are passed as char*.
sim-watch.c: In function 'watchpoint_type_to_str':
sim-watch.c:120: warning: return discards qualifiers from pointer target type
The trace_option_handler() function only uses cpu_nr when the
SIM_HAVE_ADDR_RANGE define is enabled. So move the decl down
to where the code exists. Otherwise GCC warns:
sim-trace.c: In function 'trace_option_handler':
sim-trace.c:236: warning: unused variable 'cpu_nr'
The device_error() takes a printf style string, so update the prototype
accordingly. The message should be const and it should use an attribute.
This fixes gcc warnings like:
sim-core.c: In function 'sim_core_map_attach':
sim-core.c:200: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
sim-core.c:237: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
sim-core.c: In function 'sim_core_attach':
sim-core.c:304: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
sim-core.c:314: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
sim-core.c:335: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
sim-core.c:348: warning: passing argument 2 of 'device_error' discards qualifiers from pointer target type
The gdb code always passes down -E <little|big> to the sim core when using
the sim target. But the sim core only recognizes this option when the sim
supports big endian systems. So for little endian simulators, any attempt
to use the sim target fails with:
(gdb) target sim
gdbsim: invalid option -- 'E'
unable to create simulator instance
Since always respecting the option doesn't cause any problems, do just
that. If someone tries to use an invalid endian, they'll get an error
anyways.
The common code sets up an autoconf option --enable-sim-trace which adds
-DTRACE= to CPPFLAGS. This causes warnings in the building of some files
that declare a local TRACE() helper macro. So punt it from hw-ports.c
(since it isn't actually used) and convert hw-properties.c to HW_TRACE().
Including stdbool.h before hw-properties.h results in a build error due
to the hw_add_boolean_property function having an argument named "bool"
in its prototype. The source file has already be renamed to not use
this ("boolean" instead), so match the header to the source.
* configure: Regenerate.
* config.in: Regenerate.
* main.c: Include config.h.
Use HAVE_STDLIB_H, HAVE_UNISTD_H, HAVE_GETOPT_H.
Include getopt.h in case HAVE_GETOPT_H is defined.
* compile.c(fetch_1): Fix pre-dec, pre-inc, post-dec and post-inc.
Index registers not masked memory areas.
Only simply increment or decrement.
* compile.c(store_1): Ditto.
