gnupic: gpsim's gui


Previous by date: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Craig Franklin
Next by date: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Vangelis Rokas
Previous in thread: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Craig Franklin
Next in thread: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Vangelis Rokas

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

Previous by date: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Craig Franklin
Next by date: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Vangelis Rokas
Previous in thread: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Craig Franklin
Next in thread: 14 Oct 2004 19:24:50 +0100 Re: gpsim's gui, Vangelis Rokas


Powered by ezmlm-browse 0.20.