gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Craig Franklin ####@####.####
Date:
16 Oct 2004 06:30:08 +0100
Message-Id: <41706BCB.7010603@users.sourceforge.net>
Scott Dattalo wrote:
<snip>
>
> 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.
>
Many of the addresses will be relocatable. The final addresses won't be
available to gpasm. For those symbols, gpsim will have to rely on the
symbol table.
If we use the symbol table, we should be able to get the symbol types
too. Right now we only use the unsigned byte type. I have received
information from Byte Craft on the other types. I will send more info
after I have read their data.
If we use all the symbol types, gpsim could use them to improve the
displayed symbol values.
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
