gnupic: Thread: Re: [gnupic] gputils development

David Barnett wrote:
> I know you're probably still busy with your contract projects, but do you have time to discuss a plan of action?  I'd like to figure out any changes we need to make to the pCode format before moving it over, and I'm also still nervous about how side-effects (PCLATH, computed gotos, INDF->PCL) will affect the task of determining basic blocks.
>   

I've been very busy with a bunch of stuff... I haven't spent any time on 
external clock code, but I do have some new stuff for LCD displays and 
for the 10f204.

I can take some time to discuss strategy for gputils if you like.

> A few other comments about gputils: what's involved in making a new bugfix release for the '$ label clash' bugfix?  I don't think anything's happened toward that end, and if you remember some SDCC users ran into it after the changes were in CVS.  I also think it would be a good idea to move to SVN before any more changes are made.  I don't believe I'm listed as a developer for gputils (username: merc64), and I might need that eventually.  

I can add you as a developer for gputils if you like. In fact if you 
want the CVS->SVN action item then that would be a good thing to start 
on. I'd like to run it by Craig. I haven't heard much from him in a year 
or so.

I don't have any input on the '$ label clash' bugfix since I'm not 
familiar with it.


> And lastly, I noticed that James Bowman started gpasm in 1997, so this year is (or was) gputils' 10th anniversary.
>   
And gpsim started shortly after in 1998. That's a long time!

Scott

On Thu, 24 May 2007 17:43:34 -0700
Scott Dattalo ####@####.#### wrote:

> David Barnett wrote:
> > ...
>
> I can take some time to discuss strategy for gputils if you like.
Okay, you can change the subject if you think there are more pressing
topics to address, but here's what I've been thinking.

I don't know how much trouble porting the pcode system will be as
opposed to the actual optimizations, but it's not a good starting place
for someone who doesn't know what they're doing yet (e.g. me), because
it's a lot of changes before any results come out and hence a lot of
room for misunderstanding; it's probably a one-man job for the same
reason. I know it's been a while since you worked with gputils; if
you're not up to it anytime soon, I'll just need to buckle down and fix
some of the small bugs for the next few weeks or months until I
understand the system well. There aren't many candidates for the job...

If you remember the issues I brought up with indirect addressing and
side-effects before, I think it'd be good to figure out a rough plan how
to deal with those soon, because I'm not seeing anything. My concern is
the pcode needs some order to it to be useful, and computed gotos make
it hard to isolate the entry points on the basic blocks. You have to
backtrack from the computed goto to find the value of PCLATH and the
value loaded into PCL, and the entry points are important for
backtracking, so it seems like there's a circular dependency.

> > ...
>
> I don't have any input on the '$ label clash' bugfix since I'm not 
> familiar with it.
If you don't remember, that was the thread with the subject "'pagesel
$' dup error", and also SDCC bug #1652040 and gputils bug #1652208. It
was a simple fix, but since gputils hasn't been under active
development in a while, it never got released. There are a few other
bugs regarding compatibility with MPLAB that we could maybe fix in CVS
before releasing and moving to SVN.

David Barnett

David Barnett wrote:

<snip>
> I also think it would be a good idea to move to SVN before any more changes are made.

This would be very nice. I think I already proposed the move quite some 
time ago, but I haven't got the green light from Criag. I think that you 
have to be a project administrator to make the move, so it can be done 
by Scott. It is trivial: just click on one check box on a SF web page 
and wait a day or two. I successfully did it for gpsim and sdcc projects.


Borut

----- Original Message ----- 
From: "Scott Dattalo" ####@####.####
To: ####@####.####
Sent: Thursday, May 24, 2007 7:43 PM
Subject: Re: [gnupic] gputils development


> I can add you as a developer for gputils if you like. In fact if you want 
> the CVS->SVN action item then that would be a good thing to start on. I'd 
> like to run it by Craig. I haven't heard much from him in a year or so.
I'm surprised he'd still be involved in administrative decisions.  I thought 
he was pretty much out of contact.  Let us know what you find out if you 
hear anything from him.

David Barnett 

I spent some more time today digging through the gpasm code.  The two-pass 
architecture seems very central to its functionality.  If anyone knows much 
about what happens at each pass, that could accelerate my learning process. 
I could swear I've seen some documentation about it before, but I'm not 
turning up anything now.  It looks like all the code emission and error 
reporting happens on the second pass.  I'd assume the first pass is for 
collecting macros and constants...?

I could be wrong on either count, but I think that a pcode-based 
architecture will eliminate the need for 2 passes and I think that will 
circumvent a lot of the hacks that some of the comment lines so poignantly 
lament.  In the interim I'll need to deal with the two-pass system 
regardless to knock out some bugs and figure out what I'm doing.  Maybe it 
means fixing some bugs twice, but hopefully fixing them the simplest way 
first will keep it pretty stable so we can make a quick bugfix release 
before plunging in and making huge changes.

FYI, the bugs I have in mind are differences in directives between MPASM and 
gpasm.  Two that come to mind are the severe gpasm limitations on the #v 
syntax and the order of evaluation for #defines inside macro bodies, as I 
mentioned way back in Oct '06.

David Barnett 

David Barnett wrote:
> I spent some more time today digging through the gpasm code.  The 
> two-pass architecture seems very central to its functionality.  If 
> anyone knows much about what happens at each pass, that could 
> accelerate my learning process. I could swear I've seen some 
> documentation about it before, but I'm not turning up anything now.  
> It looks like all the code emission and error reporting happens on the 
> second pass.  I'd assume the first pass is for collecting macros and 
> constants...?

You're correct, the first pass identifies and collects the symbols, 
constants, and macros. The second pass expands these and resolves 
forward references.

> I could be wrong on either count, but I think that a pcode-based 
> architecture will eliminate the need for 2 passes and I think that 
> will circumvent a lot of the hacks that some of the comment lines so 
> poignantly lament.  In the interim I'll need to deal with the two-pass 
> system regardless to knock out some bugs and figure out what I'm 
> doing.  Maybe it means fixing some bugs twice, but hopefully fixing 
> them the simplest way first will keep it pretty stable so we can make 
> a quick bugfix release before plunging in and making huge changes.

I don't think the pcode-based architecture eliminates the need for two 
passes. There are still things like forward references that have to be 
known before the pcode can operate. Now it could be that the second pass 
is completely different. For example, the first past could be 
assembly-to-pcode translation. This step also could define the pBlock 
boundaries. Once the pBlocks are known, the pCode processing can 
commence. This pcode/pblock translation step is a single pass operation. 
Manipulating pBlocks is similar to a second or multiple pass operation.

> FYI, the bugs I have in mind are differences in directives between 
> MPASM and gpasm.  Two that come to mind are the severe gpasm 
> limitations on the #v syntax and the order of evaluation for #defines 
> inside macro bodies, as I mentioned way back in Oct '06.

This fix involves the lexer and parser. BTW, in my opinion there are 
some significant improvements that can be made to the parser. Look at 
the way expressions are parsed as an example.

Speaking of expressions, a common way I emulate structures in gpasm is 
by defining EQU's that index into the structure. For example, in C I'd 
write:

 struct myStruct {
   char char1;
   char char2;
   int int1;
   int int2;
};

and in gpasm:

myStruct_char1  EQU   0
myStruct_char2  EQU   myStruct_char1 + 1
myStruct_int1  EQU   myStruct_char2 + 1
myStruct_int2  EQU   myStruct_int1 + 2
myStruct_size  EQU   myStruct_int2 + 2

Then allocate memory:

myStruct  RES myStruct_size

And then use members in struct like this:

   MOVF   myStruct + myStruct_char1,W
or
  MOVWF  myStruct + myStruct_int1 + 1    ; low byte of myStruct.int1

I found that in MPLAB you must write:

  MOVWF  myStruct + (myStruct_int1 + 1)    ; low byte of myStruct.int1

In other words, parenthesis are required around the expressions that are 
added to memory addresses. Weird! gpasm doesn't care about parenthesis here.

So, the only reason I bring this up is that the behavior of the two 
assemblers depends on the parsing. I don't think gpasm should imitate 
MPASM's idiosyncrasies!

Scott

On Fri, 25 May 2007 14:19:05 -0700
Scott Dattalo ####@####.#### wrote:

> David Barnett wrote:
> > ...
>
> I don't think the pcode-based architecture eliminates the need for
> two passes. There are still things like forward references that have
> to be known before the pcode can operate. Now it could be that the
> second pass is completely different.
Yes, that's exactly what I meant. If we add any optimization, there
will probably be *more* than 2 passes over the data, but each will be
completely distinct. The reason the two-pass property is so central to
gpasm now is it parses the same input twice and calls several functions
twice. If we translate to pcode, we won't call many major functions
twice, and I think that will have a big impact on the design.

> ...
> 
> Speaking of expressions, a common way I emulate structures in gpasm
> is by defining EQU's that index into the structure.
> ...
> In other words, parenthesis are required around the expressions that
> are added to memory addresses. Weird! gpasm doesn't care about
> parenthesis here.
I assume it gives you a "label too complex" error? That's one of the
cases where MPASM shows all the intelligence of a brick =). I know I've
complained about that on their forums before.

> So, the only reason I bring this up is that the behavior of the two 
> assemblers depends on the parsing. I don't think gpasm should imitate 
> MPASM's idiosyncrasies!
Definitely not in general. I'm pretty sure I've mentioned to you before
how much of a cop-out I think their 8-pass limit for macro
substitutions is. We could have a compatibility check flag that would
throw warnings on things that MPLAB would choke on where there's a
difference. Anyway, I think we're of the same mind as far as
compatibility: priorities are functionality, then compatibility, and
discuss first if there's any question.

However, with those differences I mentioned, I think MPASM is
significantly more powerful, and I can't see any benefit in the gpasm
way, even if well-written asm code maybe shouldn't take advantage of
them. I'd be glad to have a second opinion, but I'm pretty confident
that a few people will be glad to see those two changes made and nobody
else will notice.

David Barnett

Hi Scott,

> > Speaking of expressions, a common way I emulate structures in gpasm
> > is by defining EQU's that index into the structure.
> > ...
> > 
> > and in gpasm:
> > 
> > myStruct_char1  EQU   0
> > myStruct_char2  EQU   myStruct_char1 + 1
> > myStruct_int1  EQU   myStruct_char2 + 1
> > myStruct_int2  EQU   myStruct_int1 + 2
> > myStruct_size  EQU   myStruct_int2 + 2
> > 
> > Then allocate memory:
> > 
> > myStruct  RES myStruct_size
> > 
> > And then use members in struct like this:
> > 
> >    MOVF   myStruct + myStruct_char1,W

As an aside, when using an assembler-like language in the past to access
data structures laid out by higher-level languages I used the m4 text
processor, commonly available on Unix, to define structure building
macros allowing something like

    def_struct(touchable,
        def_int(x), def_int(y),
        def_int(w), def_int(h),
        def_uchar(pressed),
        def_uchar(sensitive),
    )

    quit_pad RES touchable_size
    MOVF quit_pad__pressed, W

m4's very powerful, much more so than the C preprocessor, and a handy
tool on occasion, leaving the assembler to just assemble.

Cheers,


Ralph.

On Wed, Nov 12, 2008 at 1:24 AM, David Barnett ####@####.#### wrote:
> It's been my experience that gputils has a steep learning curve for
> development, probably more so than the average open source project.

Or maybe the whole open source PIC development is not
so fun. gputils is good. gpsim is ok. sdcc for PIC has a long
way to go. Piklab is not moving. pk2cmd works fine. Still no
good debugger support. gnupic mailing list is quiet.

On the other hand, Microchip is moving very fast with
PIC24/dsPIC/PIC32, USB, TCP/IP, Zigbee, etc. Most
of the tools are provided under Windows. So maybe
many people (including me) are moving to PIC24 and
PIC32 since both offer good gcc based compilers which
work under Linux and Mac OS X.

Example for PIC32:
http://www.paintyourdragon.com/uc/osxpic32/index.html
http://forum.microchip.com/tm.aspx?m=364626

Now there is a new chance for lower end PIC16F with
the announcement of Enhanced PIC16F.
http://www.microchip.com/enhanced
http://forum.microchip.com/tm.aspx?m=378667

This should be a good update to people using
PIC16F. Hopefully gputils/sdcc/gpsim can catch the
opportunity.

Just some random thoughts.

Xiaofan

> On Wed, Nov 12, 2008 at 1:24 AM, David Barnett ####@####.#### wrote:
> > It's been my experience that gputils has a steep learning curve for
> > development, probably more so than the average open source project.
> 

I am working in Linux, programming PICs. But sometimes I need to work in Windows as well. Maybe my comments (as an almost-BFU) would be helpful for somebody.
> so fun. gputils is good. 
Agree - I have no problems so far

> gpsim is ok.
Yes, ok. I don't use gpsim too much. Maybe somebody can clarify - can I simulate the code written in C-language compiled with SDCC ? And what about code from Microchip MCC18 ? (I mean stepping through C-lang lines, not ASM lines)

> sdcc for PIC has a long way to go.
I am regularly experimenting with SDCC. A lot of things work. I can't get USB code working compiled with SDCC. I have to use MCC18 for it. Still do not konw why.  And maybe I would like to see some more optimizations to have code more compact. I do not need reentrant functions etc.

> Piklab is not moving.
I never used it

> pk2cmd works fine.
That is true. But I really miss chip autodetection mechanism similar to Windows' PicKit2 programmer. And I do not know how to show revision of the PIC. Maybe nice-to-have: automatically show ID and revision of the target PIC every time pk2cmd is run.

> Still no good debugger support. 
That is definitely true. Does ANY debugger for PIC on Linux exist (even some bad debugger) ? Support of PicKit2 debugger will be really cool.

Vaclav