gnupic: Thread: gpsim status

Scott Dattalo wrote:
> 
> On Sat, 26 Aug 2000, Garst R. Reese wrote:
> 
> > I have never gotten gpsim to compile. That is one of the reasons why I
> > installed v4 of readline, but these are not the same messages. But the
> > problem has always been with input.cc (info.c in the prv. msg. obv.
> > wrng.) I don't know what the problem is.
> > Garst
> 
> As soon as I finish the LCD module, I'll install readline 4 and solve this
> problem. This has been affecting too many people for too long...
> 
> Scott
> 
> PS. The LCD module is almost ready for initial release.
Fabulous, looking forward to both.
Thanks,
	Garst

Not so much status as efficiency improvements.

All I did was installed RH7.0 on my system and rebuilt gpsim. It's now about 30
to 50% faster! The only change is gcc. A simple `goto $' program would simulate
at a speed comparable to a 20MhH PIC when run on my old installation. Now it's
as fast as a 30MHz pic!

Scott

PS. Several of you responded about my ISP pleas. Well I finally found one - and
it only costs $5/month (http://dial.kfu.com/) or for $10 you can get a shell
account (http://www.kfu.com)

Those of you monitoring CVS may have seen a few changes in gpsim over the 
last couple of weeks. I've been working on attributes and command line 
expressions.

Command line expressions are really useful. In previous versions of gpsim, 
you could view the contents of a register by typing either:

   x reg_name

or

   symbol reg_name

If you wanted to change the value of  register, you had to type:

   x reg_name new_value

With command line expressions, you can examine a register simply by typing 
it's name. E.g. to view the contents of the variable named 'failures'

  gpsim> failures
failures [0x0c] = 0x84 = 0b10000100

If you want to change its value, you simply write:

  gpsim> failures = 0;

Or you can do something like this:

  gpsim> failures = temp1 * 2

or

  gpsim> failures = temp1 & 0b11110000

-----

Attributes

There have been many significant changes to the way gpsim handles 
attributes. At the moment, there's nothing really too visible on the 
outside. However, if a module has attributes, it's now possible to control 
those via the command line. The only attribute that exists in the new 
format is the X,Y coordinate of a module in the browser window. If you 
open the breadboard viewer, two floating point attributes called 'xpos' 
and 'ypos' are created. You can tinker with them just as though if they 
are symbols. Eg.

  gpsim> p16f628.xpos
  72.00000

Or you can reposition a module using the command line:

  gpsim> p16f628.xpos = 100.0

(note, since the attribute is a floating point type, only floating point 
constants can be assigned to it - there's no real good reason to make the 
attribute a floating point one; this was just the first example I 
created).

I plan to resurrect the UART module and instrument it with attributes so 
that you'll be able to write stuff like:

   U1.txbaud = 9600
   U1.txreg = 0xff   # send a break
   U1.rxreg          # display the rx register
   U1.status         # display the state of the uart module

----

GUI

I've also been tinkering with the gui. All of the changes apply to the 
'gui2' CVS tag. So far all that's been done is that the register window 
has been redesign so that it no longer uses the gtkextra sheet widget. 
It's currently not useable, but it will be soon.

Scott

On Fri, 12 Nov 2004, Scott Dattalo wrote:

> With command line expressions, you can examine a register simply by typing 
> it's name. E.g. to view the contents of the variable named 'failures'
>
> gpsim> failures
> failures [0x0c] = 0x84 = 0b10000100
>
> If you want to change its value, you simply write:
>
> gpsim> failures = 0;

And if you have a variable called quit ?

Peter

On Sat, 13 Nov 2004, Peter L. Peres wrote:

> On Fri, 12 Nov 2004, Scott Dattalo wrote:
>
>> With command line expressions, you can examine a register simply by typing 
>> it's name. E.g. to view the contents of the variable named 'failures'
>> 
>> gpsim> failures
>> failures [0x0c] = 0x84 = 0b10000100
>> 
>> If you want to change its value, you simply write:
>> 
>> gpsim> failures = 0;
>
> And if you have a variable called quit ?

It's kind of like having a variable named 'if' in C; it's an error - 
almost. In general, the command name will get resolved before the symbol. 
However, if you wrote something like:

   temp1 = quit

Then that would cause a parse error. The quit command is especially bad 
since it's 'parsed' by the lexer.


I have thought about this issue though. At the moment, variables all go 
into a symbol table with 'global' scoping. Attributes go in with 'local' 
scoping. The module name is used somewhat like a namespace name. So for 
attributes, you'd write:

   U1.xpos

where U1 is the module name and xpos is the attribute name. But for 
symbols, you just write the symbol name. What I should do is prefix 
symbols with their module name and then provide something like C++'s 
'using' command to select a default module from which symbol names can be 
resolved. That way, you could explicitly write:

   U1.temp1 = U1.quit

to display the contents of the variable 'quit'. And then after:

   using namespace U1

(or maybe a simpler 'using U1')

you could either write:

   temp1

or

   U1.temp1

to display the symbol named temp1 located in module U1.

With this approach, you'll only be constrained with module names.

Thanks for pointing this kink out to my attention - I'll fix this sooner 
rather than later.

Scott

On Sat, 13 Nov 2004, Scott Dattalo wrote:

> On Sat, 13 Nov 2004, Peter L. Peres wrote:
>
>> On Fri, 12 Nov 2004, Scott Dattalo wrote:
>> 
>>> With command line expressions, you can examine a register simply by 
>>> typing it's name. E.g. to view the contents of the variable named 
>>> 'failures'
>>> 
>>> gpsim> failures
>>> failures [0x0c] = 0x84 = 0b10000100
>>> 
>>> If you want to change its value, you simply write:
>>> 
>>> gpsim> failures = 0;
>> 
>> And if you have a variable called quit ?
>
> It's kind of like having a variable named 'if' in C; it's an error - almost. 
> In general, the command name will get resolved before the symbol. However, if 
> you wrote something like:
>
>  temp1 = quit
>
> Then that would cause a parse error. The quit command is especially bad since 
> it's 'parsed' by the lexer.
>
>
> I have thought about this issue though. At the moment, variables all go into 
> a symbol table with 'global' scoping. Attributes go in with 'local' scoping. 
> The module name is used somewhat like a namespace name. So for attributes, 
> you'd write:
>
>  U1.xpos
>
> where U1 is the module name and xpos is the attribute name. But for symbols, 
> you just write the symbol name. What I should do is prefix symbols with their 
> module name and then provide something like C++'s 'using' command to select a 
> default module from which symbol names can be resolved. That way, you could 
> explicitly write:
>
>  U1.temp1 = U1.quit
>
> to display the contents of the variable 'quit'. And then after:
>
>  using namespace U1
>
> (or maybe a simpler 'using U1')
>
> you could either write:
>
>  temp1
>
> or
>
>  U1.temp1
>
> to display the symbol named temp1 located in module U1.
>
> With this approach, you'll only be constrained with module names.
>
> Thanks for pointing this kink out to my attention - I'll fix this sooner 
> rather than later.

You are the author, I'm sure you'll find a way and make it work. Fyi I 
often have varnames like exit, reset, flags, status etc in C programs, 
where they do not collide with anything. However, when source level 
debugging problems will occur. I think that allowing direct symbol name 
typing into the environment will cause trouble. I propose some ways to fix 
it (beyond what you suggested, which is valid):

1.) use rpn.

? varname 		prints var
= varname value		sets var

2.) use what you proposed but prepend a simple dot for the 'global' 
namesapce:

exit			really exit
.exit			show variable exit
.exit = 5		set variable exit = 5
global.exit		show same exit as above (global will be a reserved
 			... name but not collide with anything
 			... it is self qualified by position)
foo.exit		show varname in module foo

3.) stick to an established convention (that of gdb f. ex.):

p varname 		print the variable contents (with some qualifier
 			flags to control casting and formatting)
set varname = value	as above

2 and 3 do not conflict imho. 2. is essentially your idea, with the global 
qualifier added.

thanks, and thanks for the great contribution,

Peter