gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Craig Franklin ####@####.####
Date:
14 Oct 2004 14:54:08 +0100
Message-Id: <416E3EE0.7040307@users.sourceforge.net>
Scott Dattalo wrote:
> On Wed, 13 Oct 2004, Craig Franklin wrote:
>
>> Scott Dattalo wrote:
>>
>>> On Wed, 13 Oct 2004, Scott Dattalo wrote:
>>>
>>>> It's a start. And just to be clear, are the new directives are in
>>>> the main branch of gputils? It looks like gpasm/directive.c CVS
>>>> version 1.49 has the new changes.
>>>
>>>
>>>
>>> And also, what is the syntax right now. I tried things like
>>>
>>> .direct a PORTC==0
>>>
>>> And I get a syntax error.
>>>
>>
>> .direct "a", "PORTC==0"
>>
>> or
>>
>> .direct 0x60 + 1, "PORTC==0"
>>
>> or
>>
>> .assert "PORTC==0"
>
>
> I hadn't tried putting the quotes around the command... Now it's time
> to start hammering out the details!
>
> Craig,
>
> I'm wondering if we're going to want to either pass more information
> to the simulator or to place more responsibility on the assembler to
> parse expressions. One of the assertions that I see being written is
> of the type:
>
> .assert "some_register & bit_mask == value"
>
> For example,
>
> #define SFLAGS ((1<<C)|(1<<Z))
>
> .assert "status & SFLAGS == (1<<C)"
>
> Unfortunately, constants like those defined in the .inc files are not
> passed through to the .o files. They are passed through for
> absolute-mode assemblies. (I can see a problem with several .o files
> defining the same constants and [potentially] confusing the linker).
> Another option is for the simulator to parse the .asm files and try to
> determine the values of constants. However, this has the drawback that
> the constant may be defined in two different ways depending on ifdef's.
>
> Any ideas here?
>
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.
The fundamental problem is that C asserts generate code to evaluate the
expressions. So complex expressions are OK. The code generates
relocations, line numbers,... This debug method doesn't generate any
code (a good thing for us), so you have less information. So we either
limit it to simple expressions or find a way to embed the data.
The simple expressions are OK for compiler generated code. It makes
life more difficult for asm users.
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.
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>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
