Subject:
Re: gpsim's gui
From:
Craig Franklin ####@####.####
Date:
13 Oct 2004 14:39:11 +0100
Message-Id: <416CE9E0.8010009@users.sourceforge.net>
Scott Dattalo wrote:
> I modifed gpsim to read the new messages. I haven't done anything
> else. I will send you what I have done.
>
> Excellent!
>
I sent the patch last night. It isn't much. I left all the hard stuff
for you to do.
>> 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.
>
Sounds good to me.
> 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 format (as stored in the file) was specified by the COD
4.0. I would really like to comply with it. Having said that, there is
nothing keeping us from modifying the contents of the string or the
command character, it is tool specific. We could introduce a delimiter,
maybe ";", to separate multiple fields within the string.
>
> 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.
>
I think the free command can be covered by the "e". When the COD file
is loaded, processes all the "e" commands and create break points all
the other 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).
>
>
> Could we write this?
>
> .direct expression break
>
>
For an assert, the spec days that program execution always halts. So I
think the break is implied. Probably because the asserts are always
critical errors. We could define a "b" command. Break if the
expression is true. The actions of gpsim might be identical(?).
>> 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.
>
I made macros for all the functions to make them easier to use. You can
always write:
.direct "e", command
or
.sim command.
I did it this way, so you could define new commands, without changing
gputils.
The rest are:
.assert <string>
.print <string>
.log <string>
>>
>> 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).
>
In the current design, you would have to do this:
.sim "fptr = fopen(<file>)"
>> 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.
>
I can see the capabilities of this really expanding in the future. So I
would like to keep gputils as simple as possible. Handle everything
with macros. Otherwise keeping gputils and gpsim synced will be a problem.
I would really like to keep within the COD spec. I understand this will
burden gpsim more, but I am willing to help to make up the difference.
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
