Add regression test support for PIC14 and PIC16
platforms, using the gpsim simulator.
Logged In: YES
gpsim and gpasm have several new features that will probably
be useful for SDCC regression tests. You may be aware of
these already, but here's a brief overview.
It's possible to embed simulation commands into a .asm file
and have gpsim execute them. (This feature works only for
relocatable mode, btw.) Probably the most useful feature is
a simulation assertion, but essentially *all* of gpsim's
commands are available. gpsim's regression/ subdirectory in
CVS provides several examples. In particular, check out the
for testing logic modules. Here's an example where the lower
3 bits of portb pass through several xor logic gates (that
effectively form a 3-input XOR gate) and are read on portc
.assert "((portc>>2) & 1) == ( ((portb>>2) ^ (portb>>1) ^
portb) & 1)"
But in general, the gpasm .assert directive is turned into a
gpsim break point that when encountered will halt the
simulation if the expression evaluates false.
Logged In: YES
I know about .assert and .sim (actually .direct) features in
gputils/gpsim. I already used them in pic14 regression tests
(sdcc/src/regression) you originally wrote (it's easy to
stand on the shoulders of giants :-).
I also adapted the usart module so that characters sent to
the serial port are written to the console, which is
required by the current platform independent regression test
framework (sdcc/support/regression). I intent to include the
module to gpsim/extras.
Done for PIC16 quite some time ago.
Still missing for PIC14: the main problem is that PIC14 port
currently doesn't support printf() - actually funtons with
Logged In: NO
Would variable arguments functions be needed except for printf?
In support/regression/fwk/lib/testfwk.c only four different
calls for printf are used, one of them being:
__printf("--- FAIL: \"%s\" on %s at %s:%u\n", szMsg,
szCond, szFile, line);
If vaargs functions are not within reach, this could be
worked around by using a combination of several
_prints(const char *s) and _printn(int n) ?
Logged In: YES
This might be a good idea: In the current argument passing
scheme, the argument list is limited to less than 15 bytes.
The call you just picked might already cross this limit (4
generic pointers: 12 bytes, 1 int: 2 bytes, total: 14 bytes).
Although I'd rather like to get varargs working (in the
course of which the "address of 1. argument does not work"
problem should be fixed as well), Frieder's proposal might
serve well as a temporary workaround... if one wants to see
all the errors the PIC port will generate ;-)
PS: I will not touch testfwk.c for now, feel free to do so.
I already have (better said I had it some time ago ;-) a
testfwk.c which doesn't use the printf() or var. args
functionality, but I don't see much sense to commit it:
pic14 is still very immature so that many regtests will
fail. And there is already a quite long list of pic14 bugs
in the bug log, which have to be solved - some of them are
already resulting from regression tests.
On the other hand, we are claiming that SDCC is "ANSI - C
compiler" and variable arguments are a part of the standard...
I still believe that in this moment is better to fix the
pic16 regression tests bugs for the next release and then
concentrate on the pic14.
I think you should commit your testfwk.c for the pic14 port.
Maybe we can use this printf-less framework for the other
In my opinion, the core of SDCC should provide the hooks
required for the regression tests of the various ports and
not the other way around. If there was a pragma mechanism
that allowed the developers to instrument a regression test,
then developers could begin to evaluate the port's integrity
much sooner. Supporting an advanced feature like variable
argument functions (which despite being part of the ANSI
standard I'd never consider using in a PIC14 based
application anyways) only hinders testing.
OK, I found it.
There is actually an other pic14 bug which prevents the
current test suite to run: [ 1427663 ] SIGSEGV on static
array of function pointers
I already localy modified the generate-cases.py script to
generate a sequence of function calls instead an array of
function pointers. This change will affect all targets.
With the __printf() removal we will loose the LOG()
functionality, so that some regression test have to be
Logged In: YES
Then define LOG empty for the ports that do not support
Function pointers are another advanced feature IMHO.
Most small devices don't even have a CALL (REGS)
instruction and you need to use the PUSH REGS, RET
Added regression test support for pic14.