gnupic: Re: [gnupic] Re: [PATCH] CONFIG feature progress
Subject:
RE: [gnupic] Re: [PATCH] CONFIG feature progress
From:
"Chen Xiao Fan" ####@####.####
Date:
25 Jan 2006 01:06:20 +0000
Message-Id: <7D4AB72251D4D949AB2732ABEABDA54F12FFF7@PFSG-MX1.ap.p-f.biz>
> -----Original Message-----
> From: Michael Ballbach
> Sent: Wednesday, January 25, 2006 2:15 AM
> To: ####@####.####
> Subject: Re: [gnupic] Re: [PATCH] CONFIG feature progress
>
> What is interesting about this is that it means that after linking
> object files together, the HEX file will not contain defaults for
> configuration bytes that you don't specifically specify. However, when
> using relative code, it does seem to fill in the defaults.
I think you mean "when using absolute code, it does seem to
fill in the defaults."
> Of course, I would consider it good practice to list every
> configuration value explicitly for the processor you are working
> with, but still, it is an interesting difference that I don't recall
> being documented in any specific way.
I agree with you that it is a good practice to list all
the configuration word explicitly. And this leads to
an easy solution: ban the use of separated configuration words
for gpasm for relocatable mode code. I think this "lazy" solution
is a good solution. ;-)
As for the solutions to allow separated configuration words,
I do not know the internals of gputils. So maybe Craig and
Scott can comment on that.
>> It is still Tuesday Jan 24 2006 here.
>> Wed Jan 25 06:07:35 2006 <maybe bug!>
>
> I'm not certain where you are located, but could this time be the time
> in GMT at the time you built the object file? Or, at least, is it just
> some static offset of hours?
>
> The patch shouldn't have affected this, but it's possible.
I am in Singapore in South East Asia (GMT+8). Singapore and
Malaysia use GMT+8 (instead of GMT+7) since it is easier for
people to deal with the business partners in the Great China Area
(mainland China, Hong Kong and Taiwan) which uses GMT+8.
The problem only pops up when viewing object file created
with MPASM. There is a fix offset of 13 hours and it reports
GMT+21. Where is time zone GMT+21? ;-)
Interestingly, I find that gpvo (unpatched and patched) reports
wrong time stamp for some old object files created by MPASM
(from PICkit 1 example) and the offset is again 13 hours.
Most of the time, gpvo reports correct time stamp.
Interestingly, gpvc does not have such problem.
I do not think your patch introduces the bug. There may
be some problems with the original gpvo code. It is not
so much a problem anyway.
C:\software\gpasm>dir intlib629.o
Volume in drive C has no label.
Volume Serial Number is AC77-5153
Directory of C:\software\gpasm
01/28/2003 09:52 AM 3,934 intlib629.o
1 File(s) 3,934 bytes
0 Dir(s) 64,335,255,040 bytes free
C:\software\gpasm>gpvo intlib629.o | more
COFF File and Optional Headers
Processor Type 12f629
Time Stamp Tue Jan 28 22:52:11 2003
Number of Sections 2
Number of Symbols 49
Characteristics 0
Regards,
Xiaofan
