[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: Scott Dattalo ####@####.#### Date: 25 May 2007 01:44:09 +0100 Message-Id: <46563136.7040705@dattalo.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: David ####@####.#### Date: 25 May 2007 03:55:10 +0100 Message-Id: <20070524214920.543107b3@DEEPTHOUGHT.BARNET.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: Borut Razem ####@####.#### Date: 25 May 2007 06:44:26 +0100 Message-Id: <465677B2.8090804@siol.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: "David Barnett" ####@####.#### Date: 25 May 2007 16:18:51 +0100 Message-Id: <002a01c79edf$659c34a0$0301a8c0@barnett2> ----- 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: "David Barnett" ####@####.#### Date: 25 May 2007 21:52:10 +0100 Message-Id: <007401c79f0d$f768cbe0$0301a8c0@barnett2> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: Scott Dattalo ####@####.#### Date: 25 May 2007 22:19:09 +0100 Message-Id: <465752C9.1040909@dattalo.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: David ####@####.#### Date: 26 May 2007 00:17:22 +0100 Message-Id: <20070525181241.6cda49de@DEEPTHOUGHT.BARNET.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: Ralph Corderoy ####@####.#### Date: 26 May 2007 10:49:27 +0100 Message-Id: <20070526094919.8172E148CCE@blake.inputplus.co.uk> 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: "Xiaofan Chen" ####@####.#### Date: 12 Nov 2008 10:09:01 -0000 Message-Id: <a276da400811120208v50b9ab3hb3804c3b0b58bff9@mail.gmail.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gputils development
From: Vaclav ####@####.#### Date: 13 Nov 2008 09:19:26 -0000 Message-Id: <4819.8868-2025-882262200-1226567927@seznam.cz> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |