[PicForth] Re: Porting questions

[J.C. Wren]

easlab at absamail.co.za wrote:

>>>>>>"JC" == J C Wren <jcwren at jcwren.com> writes:
>>>>>>            
>>>>>>
>
>  
>
>>JC> What's the scope of work involved in porting PicForth to gforth
>>JC> 0.6.2?
>>
>>    
>>
>Samuel Tardieu wrote:
>  
>
>>Probably not much but tricky. The input system has changed between
>>GForth 0.5.x and GForth 0.6.x. If someone submits the patches, I'll be
>>happy to integrate them.
>>
>>    
>>
>Who's going to test them ?
>Have we got a test harness ?
>Is there any benefit in always chasing the 'latest', imatured/unproven 
>   version?
>GForth repository seems well archived.
>I know of no problem with GForth 0.5.x.
>
>  
>
This point was primarily brought up because anyone installing gforth is 
naturally going to install the latest version, particularly if a site 
uses package management tools like apt-get, emerge, or RPMs.  For my 
personal machines, it pretty much doesn't matter.  However, I had some 
users ask about gforth for another project on a server I run, and while 
they can use --prefix to install locally, they can't replace the 
/usr/bin copy.

Obviously, there's enough differences in 0.5.0 and 0.6.2 to make a 
difference to end users.  To wit, PicForth will work with one and not 
the other.  If this is a one function name change they made (say, 
(query) vs query), then it's not a big deal.  If they've restructured 
the code generation, then yes, it's a major ordeal.

>>JC> Next, what about supporting the PIC16F8620 parts?
>>
>>Porting to a new platform with the same instruction set ought to be
>>very easy. Probably only constant definitions and such. You can look
>>at pic16f88.inc to get a taste of what it takes.
>>    
>>
>
>It's all about getting the maximum results with the available resources.
>Division of labour is a big factor.  
>   This is usually understood and not discussed.
>Of course if your a school teacher, you're looking for tasks to keep the
>kiddies busy.
>  
>
I think we're all capable of understand "division of labour".  The point 
of the question again was more along the lines of "Is this a massive 
undertaking, because PicForth is so tightly bound to the 16x parts, or 
is it relatively trivial to retarget it?".  I incorrectly typed the part 
number, it's a PIC18F8620.  How does the instruction set compare to a 
16x?  I don't really know, I have successfully managed to avoid 
programming PICs most of my career.  However, I'm working on a project 
with a PIC, and if it's possible to port PicForth to an 18x core without 
taking 24 months, I'd be a lot more inclined to put forth the effort in 
such a port.

So I will again restate the question a little more clearly: Is porting 
PicForth to an 18x part a massive undertaking requiring 6 months of 
people with only the deepest understanding of PicForth internals, or can 
a reasonably competent programmer with 20 years experience, little 
experience with gforth and some experience with PICs hope to port from a 
16F88 to a PIC18F8620 in less than 6 months with only questions to the 
principle architects?

>== Chris Glur.
>_______________________________________________
>PicForth mailing list
>PicForth at lists.rfc1149.net
>http://lists.rfc1149.net/mailman/listinfo/picforth
>
>  
>