gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Scott Dattalo ####@####.####
Date:
13 Oct 2004 08:17:40 +0100
Message-Id: <Pine.LNX.4.60.0410122209270.7107@ruckus.brouhaha.com>
On Tue, 12 Oct 2004, Craig Franklin wrote:
<snip>
> I modifed gpsim to read the new messages. I haven't done anything else. I
> will send you what I have done.
Excellent!
> 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:
FYI. I've added two new capabilities to gpsim recently. First, the concept
of a break point has been split into a trigger and an action. There is a
C++ class called TriggerObject that contains a TriggerAction. A breakpoint
is a C++ class derived from the TriggerObject and Instruction classes and
contains a SimpleTriggerAction that when invoked halts the simulation.
An assertion is similar. At the moment the implementation is fairly
simple, but eventually I intend for other kinds of actions like logging,
printf's, profiling, etc. to be paired with triggers.
The other feature recently added was expression parsing at the command
line.
Rather than define a sequence of commands that blend together the triggers
and action concepts it might be better to split these apart in the new
directives. For example, suppose the directive syntax was this:
.directive [modifier] [expression] action
The '.directive' is the name of the directive (I already forgot what they
are...). The modifier is optional field that describes how the expression
and action are to be associated with code. If there is no modifier then
the directive is associated with the instruction immediately following it.
This could be called the 'pre' condition. A 'post' condition means that
the expression and action are evaluated *after* the instruction that
precedes it. There are subtle differences in behavior between a pre and
post assertion and just moving the assertion up or down a line in the
source. I probably should give an example. A third kind of modifier would
be 'free', which is to say that it is not associate with any instruction
and is operated on whenver the code is loaded. This could be useful for
embedding scripts directly into .asm source code.
The expression, if present, is evaluated. If the evaluation is true, then
the action is then processed.
The action is a command or a statement, like break or print or log or any
valid simulator command.
> 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).
Could we write this?
.direct expression break
> Emulator/Simulator (e) - Execute the gpsim command in the sting. Can we pass
> it to the cli parser? That could make this one simple.
There is a way to send a command directly to the parser. (It's
parse_string(char *) in cli/input.cc).
So we could write:
.direct command
The 'command' can be fed to the command line parser.
>
> 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.
.direct command
Where command would be 'printf(string)' for right now, and printf(string,
variable args) later on. (Currently, gpsim supports only an 'echo'
command').
> Log (l) - Just like Print but the output goes to the log file instead of
> stdout.
.direct command
Where command is fprintf and the file is fopen'd earlier by
.direct free fptr = fopen("file")
(I don't like 'free' for the modifier name - perhaps unattached,
nonassociated (or non), or whatever). (Also, at the moment gpsim has a
very kludgy way dealing with assignent statments).
> 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.
I agree on the flexibility.
Scott
