gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Craig Franklin ####@####.####
Date:
13 Oct 2004 04:56:11 +0100
Message-Id: <416C613A.5000402@users.sourceforge.net>
Scott Dattalo wrote:
> On Tue, 12 Oct 2004, Craig Franklin wrote:
>
>> Craig Franklin wrote:
>>
>>> Scott Dattalo wrote:
>>>
>>>>
>>>> I'm sure anything can be done! It's just a matter of time and
>>>> effort. What I'm thinking about here is parsing the .asm text (like
>>>> we do already) and defining regions around key portions of the text
>>>> (like variables). These regions can have enter/leave events
>>>> associated with them and those events could show/hide tool tips.
>>>>
>>>
>>> Can you add "support for the BCDIRECT messages" to the list?
>>
>>
>>
>> I will try to get this one started and send you a patch later.
>
>
> I'd like to support all of the new gputils 0.13.0 features before the
> gui is modified. It'd probably make sense to make a gpsim release
> coinciding with the gputils release.
>
Sounds good to me.
I modifed gpsim to read the new messages. I haven't done anything
else. I will send you what I have done.
With each message you get a program memory address, a single character
command, and a string. I was thinking a break point would be created
for each message at the address. The command would dictate what action
would be taken at the break. There are 4 common commands:
Assert (a) - If the expression is true (non-zero) halt execution and
print a message. Probably need to parse the expressions when the COD
file is loaded, to keep gpsim fast. Maybe limit it to simple
expressions at first (my_pic_memory = 0).
Emulator/Simulator (e) - Execute the gpsim command in the sting. Can we
pass it to the cli parser? That could make this one simple.
Printf (f) - The example shows a complex expression in the string, just
like printf inputs. This might be tricky to parse. Maybe limit it to
fixed strings with no arguments at first.
Log (l) - Just like Print but the output goes to the log file instead of
stdout.
These are the common commands. We can define any new commands we want.
To me, the emulator/simulator command should be flexible enough for
anything.
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
