gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Scott Dattalo ####@####.####
Date:
14 Oct 2004 19:24:50 +0100
Message-Id: <Pine.LNX.4.60.0410141034450.12005@ruckus.brouhaha.com>
On Thu, 14 Oct 2004, Craig Franklin wrote:
<snip>
> We should try to keep the simulator from having to parse any asm files. That
> is gpasm's job. There are too many special cases to handle without including
> gpasm's parser in gpsim. That isn't practical.
I fully agree. And Vangelis' comments add even more support.
<snip>
> Maybe if the argument is a string, gpasm copies it, unmodified, to the debug
> message. If the argument is an expression, the constants are evaluated.
> Then the expression is converted to a string and copied to the debug message.
I think this is an excellent solution.
>
> A disadvantage is that the assert message that gpsim outputs would be a
> little more cryptic. That is ok because execution stops at the assert. The
> user can see original expression in the source code.
>
> I need to think about this more. Maybe we should start by defining what
> events we will support. The best solution might be obvious then. I don't
> think we need to support every possible expression. We need to generate an
> assert list like:
>
> memory == value
> bit == value
> ...<add to list here>
In essence, your suggestion is to let gpasm/gplink parse an expression and
turn it into a form that can then be parsed by the simulator. It may help
to introduce types. So for example, to check if the carry bit is set and
the Z bit is clear we could write:
.assert STATUS & FLAGS == (1<<C)
Which when parsed by gpasm would be turned into:
char(0x03) & 0x05 == 0x01
The simulator can treat char() as an operator that returns a byte from
register memory (in this case, address 3). The constants are just numbers.
Here's a proposed list of operators:
char(ram_address) -- returns unsigned byte from ram
int(ram_address) -- returns unsigned 16-bit value from ram
(i.e. the two bytes at ram_address and
ram_address+1)
long(ram_address) -- returns
rom(rom_address) -- returns the contents of program memory
the size is processor dependent.
I think having types like these will simplify assertion expressions for
SDCC and gpal.
Scott