Raphael,
On Sun, Feb 24, 2013 at 11:29:37PM +0100, Raphael Neider wrote:
> I hope it helped: I have committed a fix as r8441 and would highly
> appreciate if you could verify that the bug is gone. (I would also
> appreciate if you informed me that the bug persists, though that
> report would be so
Hi,
> Yes, you are right of course. Thanks for investigating further, I read
> the remainder of your post with great interest. Unfortunately this is a
> little bit too much for me in the moment, I wont be able to find the
> time to acquire the necessary background knowledge to come up with a
> sol
Raphael,
On Wed, Feb 20, 2013 at 08:46:58PM +0100, Raphael Neider wrote:
> I had a look at the problem. Actually,
[code that produces a broken long2fs]
> is equivalent to
[code that coincidentally works]
> and the latter saves code for one comparison. So changing that
> *should* not break/heal an
On 20.02.2013 19:11, Raphael Neider wrote:
> The problem (well, one of the problems, really :-[) with the PIC
> libraries is that they intentionally diverged from SDCCs standard
> library (before "my" time already, though I did nothing to revert
> that). When the library started to diverge, source
Hi,
I had a look at the problem. Actually,
if (a < HIDDEN)
{
do { /* something */ } while (a < HIDDEN);
}
is equivalent to
while (a < HIDDEN)
{
/* something */
}
and the latter saves code for one comparison. So changing that
*should* not break/heal anything.
I did not check that. I dug in
Hi,
>> I then looked in sdcc/devices/lib/_ulong2fs.c, which also uses the
>> bottom version. Why do different devices have copies of (almost) the
>> same code in various places?
>> Shouldn't they all use the same to avoid situations like this?
>
> don't know for this case. In general, we have one
On 20.02.2013 13:08, Daniel Michalik wrote:
> I then looked in sdcc/devices/lib/_ulong2fs.c, which also uses the
> bottom version. Why do different devices have copies of (almost) the
> same code in various places?
> Shouldn't they all use the same to avoid situations like this?
don't know for
[resent after sending from the wrong mail address earlier]
On Wed, Feb 20, 2013 at 12:05:15PM +0100, Daniel Michalik wrote:
> The asm block "functions called" is identical expect for the additional
> "___slong2fs" in the not working example. I am not sure whether that is
> sufficient indication to
On Wed, Feb 20, 2013 at 11:32:05AM +0100, Maarten Brock wrote:
> I seem to remember that the SDCC PIC14 port does not have any working
> initialization of global variables.
I think it generally should work. I used them before and it worked fine
(assuming there wasn't any optimization doing magic).
On Wed, Feb 20, 2013 at 12:05:27AM -0600, Erik Petrich wrote:
> I can't answer most of your questions because I do use pic and so I am not
> very familiar with that part of SDCC. However, I can answer why SDCC does
> not need to call __fs2uint in the first example. SDCC's optimizations are
> all
>> unsigned int debug = 1234;
>> float julianday = 6116.0;
>>
>> void main(void) {
>> float x = 6116.0;
>>
>> debug = julianday;
>> // expect 6116, obtain a vastly different (arbitrary?) number
>> }
[...]
> If this leaves the correct value in debug, the problem is with
> initializat
On Mon, 18 Feb 2013, Daniel Michalik wrote:
> When comparing the asm outputs I see that the first example does not call
> ___fs2uint, why does it not need to do this to cast the value of x?
> void main(void) {
> float x = 6116.0;
> debug = x;
> //debug is 6116.
> }
> unsigned
12 matches
Mail list logo
