gnupic: Thread: Re: [gnupic] Fwd: Patches for gputils-0.13.4

On 7/11/07, Scott Dattalo ####@####.#### wrote:
> Hi Andreas,
>
> Thanks for adding support for Microchip's new Coff format. I'm sorry that
> Craig hasn't responded to your messages. I've been unresponsive lately
> too. (And in the next few days I'll not have access to a computer).
> However, I don't want this patch to get lost. I haven't had a chance to
> look at, but I'm forwarding it to the gnupic mailing list so that perhaps
> someone else can.
>
> Scott
>
> ---------------------------- Original Message ----------------------------
> Subject: Patches for gputils-0.13.4
> From:    "Andreas Kabel" ####@####.####
> Date:    Tue, July 10, 2007 10:59 pm
> To:      ####@####.####
> --------------------------------------------------------------------------
>
> Hi Scott -- is this project (gputils) still being maintained? I have
> tried to
> contact Craig Franklin some in the past, but never received a response.
> Anyway, I have a set of patches for gplink/gpasm which allow for support
> of Microchip's new Coff format; perhaps this is something which should
> go in any new release of the gputils.
>
> Andreas
>

Andreas:

Another COFF patch has already been accepted into the CVS code.
Last time I tested and it was ok. Not so sure if this new patch is necessary
or not. Maybe you can test the latest CVS version and see if it has already
fixed the issue.

https://sourceforge.net/tracker/index.php?func=detail&aid=1498595&group_id=41924&atid=431667

CVS Changelog:
2007-06-25 David Barnett ####@####.####
   17   * [gputils] Patch by Michael Ballbach to add support for new COFF format

----- Original Message ----- 
From: "Xiaofan Chen" ####@####.####
To: ####@####.####
Sent: Wednesday, July 11, 2007 10:54 AM
Subject: Re: [gnupic] Fwd: Patches for gputils-0.13.4


>> ---------------------------- Original 
>> Message ----------------------------
>> Subject: Patches for gputils-0.13.4
>> From:    "Andreas Kabel" ####@####.####
>> Date:    Tue, July 10, 2007 10:59 pm
>> To:      ####@####.####
>> --------------------------------------------------------------------------
>>
>> Anyway, I have a set of patches for gplink/gpasm which allow for support
>> of Microchip's new Coff format; perhaps this is something which should
>> go in any new release of the gputils.
>>
>> Andreas
>
> Andreas:
>
> Another COFF patch has already been accepted into the CVS code.
> ...
> https://sourceforge.net/tracker/index.php?func=detail&aid=1498595&group_id=41924&atid=431667
> ...

Andreas,

Xiaofan is correct. I applied that patch a week or two ago. However, that 
patch only affects gpvo, not gpasm or (IIRC) gplink. I will definitely apply 
your patch or something like it sooner or later, but since I'm rather new to 
this and you know more about the necessary changes, you might consider 
comparing the patches and merging the changes into one patch (against the 
latest CVS version, which already has the other patch applied). It may just 
involve removing the gpvo-related changes from your patch, but I suspect 
there's a little more to it than that. I'll still be reviewing the changes 
before I apply them, so whether or not you merge the changes, you could 
directly email me any notes or related background info if you want (call it 
a favor).

About the next release, I'm in the middle of some messy changes involving 
#defines and macro parameters, but I might go ahead and release 0.13.5 soon 
and save those changes for another release. Several important changes have 
been made since the last release, and that was almost a year ago besides. I 
believe many gputils users don't check the CVS repository and would 
appreciate a new release.

I copied you directly this time since I'm not sure if you're checking the 
gnupic list, but I'd recommend subscribing to it ####@####.#### if 
you haven't. I can forward you Xiaofan's message if you missed it.

David Barnett 

David Barnett wrote:
> ----- Original Message ----- From: "Xiaofan Chen" ####@####.####
> To: ####@####.####
> Sent: Wednesday, July 11, 2007 10:54 AM
> Subject: Re: [gnupic] Fwd: Patches for gputils-0.13.4
> 
> 
>>> ---------------------------- Original Message 
>>> ----------------------------
>>> Subject: Patches for gputils-0.13.4
>>> From:    "Andreas Kabel" ####@####.####
>>> Date:    Tue, July 10, 2007 10:59 pm
>>> To:      ####@####.####
>>> -------------------------------------------------------------------------- 
>>>
>>>
>>> Anyway, I have a set of patches for gplink/gpasm which allow for support
>>> of Microchip's new Coff format; perhaps this is something which should
>>> go in any new release of the gputils.
>>>
>>> Andreas
>>
>> Andreas:
>>
>> Another COFF patch has already been accepted into the CVS code.
>> ...
>> https://sourceforge.net/tracker/index.php?func=detail&aid=1498595&group_id=41924&atid=431667 
>>
>> ...
> 
> Andreas,
> 
> Xiaofan is correct. I applied that patch a week or two ago. However, 
> that patch only affects gpvo, not gpasm or (IIRC) gplink. I will 
> definitely apply your patch or something like it sooner or later, but 
> since I'm rather new to this and you know more about the necessary 
> changes, you might consider comparing the patches and merging the 
> changes into one patch (against the latest CVS version, which already 
> has the other patch applied). It may just involve removing the 
> gpvo-related changes from your patch, but I suspect there's a little 
> more to it than that.

Hi David -- yes, my changes involve the complete toolchain, i.e.,
gpasm can generate either new or old format COFF (with an additional
command-line option) and gplink and gpvo can both handle new and old 
format COFFs (and mixes thereof). I'd be happy to reconcile your patches
and mine into a single one. I recently noticed, however, that all 
COFF-related stuff is platform-dependent, as it assumes that sizeof(long 
int)==4 and sizeof(short)==2, which is not necessarily true. It might 
make sense to rework the patch to take care of this issue.

> I'll still be reviewing the changes before I apply 
> them, so whether or not you merge the changes, you could directly email 
> me any notes or related background info if you want (call it a favor).
> 
> About the next release, I'm in the middle of some messy changes 
> involving #defines and macro parameters, but I might go ahead and 
> release 0.13.5 soon and save those changes for another release. Several 
> important changes have been made since the last release, and that was 
> almost a year ago besides. I believe many gputils users don't check the 
> CVS repository and would appreciate a new release.

I for one didn't check ... BTW, the CVS server given on the sourceforge 
is incorrect, it should be pserver:gputils.cvs.sourceforge.net.

> 
> I copied you directly this time since I'm not sure if you're checking 
> the gnupic list, but I'd recommend subscribing to it 
> ####@####.####

Yes, I'll do that.

Thanks,

	Andreas

On Wednesday 11 July 2007 09:52, David Barnett wrote:
[....]
> Several important changes have been made since the last release, and
> that was almost a year ago besides. I believe many gputils users
> don't check the CVS repository and would appreciate a new release.

Speaking for myself and I'm sure many other users.  I certainly never 
look at the CVS.  Since I currently am purely a user and in no way a 
developer and my copy of the gputils is working for what I need to do 
today, I won't even update to a new released version until after I am 
done with what I'm working on.  

I have learned through sad experience that if software is working never 
ever ever ever update to a new version.

When I am done with this project, I may download the new version and try 
it out just because I would be curious.


####@####.####

Le mercredi 11 juillet 2007, David Barnett a écrit :

> About the next release, I'm in the middle of some messy changes involving
> #defines and macro parameters, but I might go ahead and release 0.13.5 soon
> and save those changes for another release. Several important changes have
> been made since the last release, and that was almost a year ago besides. I
> believe many gputils users don't check the CVS repository and would
> appreciate a new release.

+1
I think the release cycle of gputils and gpsim is really too long.

Regards,
Alain
-- 
Les pages de manuel Linux en français
http://manpagesfr.free.fr/

----- Original Message ----- 
From: ####@####.####
To: ####@####.####
Sent: Friday, July 13, 2007 10:19 AM
Subject: Re: [gnupic] Fwd: Patches for gputils-0.13.4


> On Wednesday 11 July 2007 09:52, David Barnett wrote:
> [....]
>> Several important changes have been made since the last release, and
>> that was almost a year ago besides. I believe many gputils users
>> don't check the CVS repository and would appreciate a new release.
>
> Speaking for myself and I'm sure many other users.  I certainly never
> look at the CVS.  Since I currently am purely a user and in no way a
> developer and my copy of the gputils is working for what I need to do
> today, I won't even update to a new released version until after I am
> done with what I'm working on.
>
> I have learned through sad experience that if software is working never
> ever ever ever update to a new version.
I wholeheartedly agree. That's especially important for developers, where 
broken functionality can mean a QA problem for customers. And it's amazing 
what tiny changes can blow up in your face...

In fact, if your code already works correctly, none of the changes since 
0.13.4 will improve it! The COFF format enhancements, already added in gpvo 
and still to be added in gpasm and gplink, might be directly useful to you 
in the future. Also the CONFIG and pageselw directives work now. But the 
compatibility problems are still my top priority.

OTOH, the first change since last release, the duplicate label issue with 
'$', has hit several people that I know of, so I don't want to make the 
users resort to using CVS to work around it.

David Barnett 

On Wed, 11 Jul 2007 10:55:54 -0700
Andreas Kabel ####@####.#### wrote:
> >>> ---------------------------- Original Message 
> >>> ----------------------------
> >>> Subject: Patches for gputils-0.13.4
> >>> From:    "Andreas Kabel" ####@####.####
> >>> Date:    Tue, July 10, 2007 10:59 pm
> >>> To:      ####@####.####
> >>> -------------------------------------------------------------------------- 
> >>> Anyway, I have a set of patches for gplink/gpasm which allow for
> >>> support of Microchip's new Coff format; perhaps this is something
> >>> which should go in any new release of the gputils.  
Andreas, I've finally gotten around to merging your changes into the
gputils SVN repository. They're included in rev 510. A few more details
are attached in the patch tracker:
https://sourceforge.net/support/tracker.php?aid=1752107

My fault for missing the 0.13.5 release, but I plan to release 0.14.0
soon with all of these new features.

@all: Please test extensively ('gpasm -C' generates new-style COFF).

> I recently noticed, however, that all COFF-related stuff is
> platform-dependent, as it assumes that sizeof(long int)==4 and
> sizeof(short)==2, which is not necessarily true. It might make sense
> to rework the patch to take care of this issue.  
I didn't touch this issue, but it probably makes sense to treat it
separately. For one thing, it would help if whoever made the changes
had a different platform that had size-related failures so that we
could do at least a little testing. Also, I believe the size changes
affect more than just the lines changed in the patch.

If you'd like to revisit the issue yourself, I promise to get it into
SVN right away this time =).

David Barnett

Andreas Kabel ####@####.#### wrote:

>> I recently noticed, however, that all COFF-related stuff is
>> platform-dependent, as it assumes that sizeof(long int)==4 and
>> sizeof(short)==2, which is not necessarily true. It might make sense
>> to rework the patch to take care of this issue.
>>     

Are you saying that the problem existed already in the old COFF 
implementation? This is probably not true since I've successfully used 
gputils to run sdcc regression tests for pic target on amd64 machine, 
where sizeof(long int)==8...

Borut

On Wed, 14 Nov 2007 19:03:30 +0100
Borut Razem ####@####.#### wrote:

> Andreas Kabel ####@####.#### wrote:
> 
> >> I recently noticed, however, that all COFF-related stuff is
> >> platform-dependent, as it assumes that sizeof(long int)==4 and
> >> sizeof(short)==2, which is not necessarily true. It might make
> >> sense to rework the patch to take care of this issue.
> >>     
> 
> Are you saying that the problem existed already in the old COFF 
> implementation?
If that question was directed at me, I don't really know. The
intermediate results get stored in short and long int types, not e.g.
types from sys/types.h. I don't know if and where there would be
problems.
> This is probably not true since I've successfully used gputils to run
> sdcc regression tests for pic target on amd64 machine, where
> sizeof(long int)==8...
I'm not sure what the issues would be, but I don't think they would be
extreme in any case. Except for a few cases documented in the bug
report here:
https://sourceforge.net/tracker/index.php?func=detail&aid=803352&group_id=41924&atid=431665
it looks like all COFF data accesses use gp_get* and gp_fput* which
handle endianness and data width explicitly. I can't be sure I know
exactly what Andreas is referring to, but I think that since the
standard requires:
 sizeof(short)>=2
 sizeof(long int)>=4
that any such issue would probably not lose meaningful precision.

Andreas' vacation autoreply said that he would be away from email until
the 11/21, so maybe he'll be able to clarify when he gets back.

David Barnett

David wrote:
> I'm not sure what the issues would be, but I don't think they would be
> extreme in any case. Except for a few cases documented in the bug
> report here:
> https://sourceforge.net/tracker/index.php?func=detail&aid=803352&group_id=41924&atid=431665
>   

This bug report is about endianness and not about diferent widths. The 
problem is that the data is acessed direcltly and not using gp_get*, 
which (at least should) solve both endianness and size problems.

> it looks like all COFF data accesses use gp_get* and gp_fput* which
> handle endianness and data width explicitly. I can't be sure I know
> exactly what Andreas is referring to, but I think that since the
> standard requires:
>  sizeof(short)>=2
>  sizeof(long int)>=4
> that any such issue would probably not lose meaningful precision.
>   

I agree. The problem might be sizeof(int), which is 2 on 16bit machines, 
but gputils probably doesn't run on any of them ;-)

> Andreas' vacation autoreply said that he would be away from email until
> the 11/21, so maybe he'll be able to clarify when he gets back.
>   

OK, let wait for Andreas...

Borut