[sdcc-devel] [ sdcc-Support Requests-2994916 ] problem in static structure intialization

[SourceForge.net <noreply@so...>]

Support Requests item #2994916, was opened at 2010-04-30 11:55
Message generated for change (Tracker Item Submitted) made by ramey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994916&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem in static  structure intialization

Initial Comment:
problem initializing structures.

When I have code like

static struct s = {
const void (*fpr)();
...
...
} = {
...

I notice when tracing through with the debugger that the target of fptr is the ADDRESS of the function rather than the variable "fptr"

See attached code and asm list



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994916&group_id=599

[sdcc-devel] [ sdcc-Bugs-2994867 ] TF2CEN bit in wrong location in headers

[SourceForge.net <noreply@so...>]

Bugs item #2994867, was opened at 2010-04-30 18:17
Message generated for change (Tracker Item Submitted) made by sjborley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2994867&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steven Borley (sjborley)
Assigned to: Nobody/Anonymous (nobody)
Summary: TF2CEN bit in wrong location in headers

Initial Comment:
The TF2CEN bit  in the Timer2 configuration register should be at bit-4 not bit-5 in TMR2CN:.  Several headers have it at the wrong location.

The attached file patches all headers where this is relevant

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2994867&group_id=599

[sdcc-devel] [ sdcc-Support Requests-2994795 ] floating point error in handling - 0.0

[SourceForge.net <noreply@so...>]

Support Requests item #2994795, was opened at 2010-04-30 08:37
Message generated for change (Tracker Item Submitted) made by ramey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994795&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: floating point error in handling - 0.0

Initial Comment:
float x;
...
0.0f != - x

That is, IEEE negative zero is not properly accounted for.  In this case, this is handled by the compiler rather than a library so it has to be addressed in the compiler itself.

Attached you'll find the original test program and an excerpt from the generated assembly

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994795&group_id=599

[sdcc-devel] [ sdcc-Support Requests-2994395 ] Caught signal 11: SIGSEGV

[SourceForge.net <noreply@so...>]

Support Requests item #2994395, was opened at 2010-04-29 14:31
Message generated for change (Comment added) made by ramey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Caught signal 11: SIGSEGV

Initial Comment:
I'm gettting "Caught signal 11: SIGSEGV" in several files when I try to compile a c module.

This only started to occur when I upgraded to 2.9 release.

Any help would be appreciated.

Robert Ramey


----------------------------------------------------------------------

>Comment By: Robert Ramey (ramey)
Date: 2010-04-30 08:28

Message:
The following code produces this error

/*
 * display one icon. used for displaying screen icon 
 * without using sprites.
 */
local void
display_impl(UINT8 col, UINT8 row, UINT8 width, UINT8 depth, UBYTE
*tiles){
    rendering r = {
        col,
        row,
        width,
        depth
    };
    r.tile = tiles;
    display_append_icon_rendering(&r);
}

Making the data item "rendering" static makes the error go away.

Hope this is helpful.

Robert Ramey



----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2010-04-30 02:40

Message:
Robert,

Can you please attach some code that produces this error? Without it
really is impossible to help.

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

[sdcc-devel] [ sdcc-Support Requests-2994395 ] Caught signal 11: SIGSEGV

[SourceForge.net <noreply@so...>]

Support Requests item #2994395, was opened at 2010-04-29 23:31
Message generated for change (Comment added) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Caught signal 11: SIGSEGV

Initial Comment:
I'm gettting "Caught signal 11: SIGSEGV" in several files when I try to compile a c module.

This only started to occur when I upgraded to 2.9 release.

Any help would be appreciated.

Robert Ramey


----------------------------------------------------------------------

>Comment By: Maarten Brock (maartenbrock)
Date: 2010-04-30 11:40

Message:
Robert,

Can you please attach some code that produces this error? Without it
really is impossible to help.

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

[sdcc-devel] [ sdcc-Support Requests-2994395 ] Caught signal 11: SIGSEGV

[SourceForge.net <noreply@so...>]

Support Requests item #2994395, was opened at 2010-04-29 14:31
Message generated for change (Tracker Item Submitted) made by ramey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Caught signal 11: SIGSEGV

Initial Comment:
I'm gettting "Caught signal 11: SIGSEGV" in several files when I try to compile a c module.

This only started to occur when I upgraded to 2.9 release.

Any help would be appreciated.

Robert Ramey


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2994395&group_id=599

[sdcc-devel] PIC14 (and maybe other ports as well) questions/requests

[Vaclav Peroutka <vaclavpe@se...>]

Hello all,

I have two questions or requests (if it can be implemented) :
- is it possible to specify manually which bank should be used for a particular variable - New keyword "bank" can be used. For example, variable declaration can be like that:
bank 0 unsigned char icnt;

- How can I use variables inside asm code ? I can not compile following example:

void delay_us (unsigned char us_cnt)   // Delay in microseconds
{   // 3 cycles on function entry. At 16MHZ crystal we have 4 cycles per 1us
   __asm
us_loop:
   NOP               // 1 cycle
   DECFSZ   us_cnt, f   // 1 cycle
   GOTO   us_loop      // 2 cycles
   __endasm;
}   // 2 clocks on return

Thank you in advance,
Vasek

[sdcc-devel] [ sdcc-Feature Requests-2991122 ] C99 designated initializer support

[SourceForge.net <noreply@so...>]

Feature Requests item #2991122, was opened at 2010-04-22 17:39
Message generated for change (Comment added) made by cananian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: C. Scott Ananian (cananian)
Assigned to: Nobody/Anonymous (nobody)
Summary: C99 designated initializer support

Initial Comment:
Add support for C99 "designated initializers", like:

struct {
   int x, y;
} point = { .y = 3, .x = 2 };

----------------------------------------------------------------------

>Comment By: C. Scott Ananian (cananian)
Date: 2010-04-22 21:18

Message:
I attached an updated patch which honors initializer order, as the spec
says we ought.

For yr reference, here's my test case; I've examined the assembly output
for mcs51, pic, and pic16 and convinced myself it's correct:

/** Tests for designated initializers */
struct point { int x, y; };
//char __code simpletest[] = "foo";
int a1[6] = { [4] = 29, 30, [2] = 15 };
int __code a2[6] = { [4] = 29, 30, [2] = 15 };
unsigned char widths1[] = { [2] = 2, [20] = 3, [2] = 1 };
unsigned char __code widths2[] = { [2] = 2, [20] = 3, [2] = 1 };

int foo(int xvalue, int yvalue) {
    struct point p = { .y = yvalue, .x = xvalue };
    return p.x + p.y;
}
struct point p1 = { .y = 2, .x = 1 };
struct point __code p2 = { .y = 2, .x = 1 };

struct point pa1[] = { { 1 } };

union foo { int i; float d; };
union foo f1 = { .d = 4 };
union foo __code f2 = { .d = 4 };
union foo __code f3 = { .i = 4 };

int whitespace1[256]
       = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
           ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
int __code whitespace2[256]
       = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
           ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };

struct test {
    int x;
    int y1 : 2;
    int    : 2;
    int y2 : 3;
    int z;
};
struct test stest1 = { .y1 = 1, 3, 4, .x = 2, .z = 5 };
struct test __code stest2 = { .y1 = 1, 3, 4, .x = 2, .z = 5 };

const char *foo1 = "bar";
char * __code foo2 = "bat";

struct point ptarray1[10] = { [2].y = 5, [2].x = 6, [0].x = 7 };
struct point __code ptarray2[10] = {
    [2].y = 5,
    [2].x = 6,
    [0].x = 7,
    [2].x = 8 };

void main(void)
{
}


----------------------------------------------------------------------

Comment By: C. Scott Ananian (cananian)
Date: 2010-04-22 18:43

Message:
The standard seems to use "designation" to mean "a sequence of one or more
designators".  I tried to use this definition in the code as well.

Good catch on the order of initialization.  My original patches followed
the initializer order more closely, but I reworked it to try to remove some
duplicate code.  I can go back to the version that respects the initializer
order.

We do in fact omit initialization for holes; the code you're looking at is
for 'code' segment initializations, where we emit a static set of '.db'
statements -- obviously we can't skip holes here.

----------------------------------------------------------------------

Comment By: Philipp Krause (spth)
Date: 2010-04-22 18:31

Message:
- Should the term "designation initializer" be used in place of "designated
initalizer"? The first term is the one used in the C standard, while the
second oine is used in the rationale.

- Does the standard mandate that the initializations occour in a given
order? E.g. we have a volatile struct, inilialized using a designation
initalizer that lists the second member before the second do we have to
really initialize the second member first? Verse 1670-1672 seems to suggest
so to me (who doesn't really know anything about designation
initializers).

- The has a comment "If this is a hole, substitute an appropriate
initializer." Unless the object is static, can we increase efficiency by
not doing the initialization for these holes instead of initializing them
to 0?

Philipp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

[sdcc-devel] [ sdcc-Feature Requests-2991122 ] C99 designated initializer support

[SourceForge.net <noreply@so...>]

Feature Requests item #2991122, was opened at 2010-04-22 17:39
Message generated for change (Comment added) made by cananian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: C. Scott Ananian (cananian)
Assigned to: Nobody/Anonymous (nobody)
Summary: C99 designated initializer support

Initial Comment:
Add support for C99 "designated initializers", like:

struct {
   int x, y;
} point = { .y = 3, .x = 2 };

----------------------------------------------------------------------

>Comment By: C. Scott Ananian (cananian)
Date: 2010-04-22 18:43

Message:
The standard seems to use "designation" to mean "a sequence of one or more
designators".  I tried to use this definition in the code as well.

Good catch on the order of initialization.  My original patches followed
the initializer order more closely, but I reworked it to try to remove some
duplicate code.  I can go back to the version that respects the initializer
order.

We do in fact omit initialization for holes; the code you're looking at is
for 'code' segment initializations, where we emit a static set of '.db'
statements -- obviously we can't skip holes here.

----------------------------------------------------------------------

Comment By: Philipp Krause (spth)
Date: 2010-04-22 18:31

Message:
- Should the term "designation initializer" be used in place of "designated
initalizer"? The first term is the one used in the C standard, while the
second oine is used in the rationale.

- Does the standard mandate that the initializations occour in a given
order? E.g. we have a volatile struct, inilialized using a designation
initalizer that lists the second member before the second do we have to
really initialize the second member first? Verse 1670-1672 seems to suggest
so to me (who doesn't really know anything about designation
initializers).

- The has a comment "If this is a hole, substitute an appropriate
initializer." Unless the object is static, can we increase efficiency by
not doing the initialization for these holes instead of initializing them
to 0?

Philipp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

[sdcc-devel] [ sdcc-Feature Requests-2991122 ] C99 designated initializer support

[SourceForge.net <noreply@so...>]

Feature Requests item #2991122, was opened at 2010-04-22 23:39
Message generated for change (Comment added) made by spth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: C. Scott Ananian (cananian)
Assigned to: Nobody/Anonymous (nobody)
Summary: C99 designated initializer support

Initial Comment:
Add support for C99 "designated initializers", like:

struct {
   int x, y;
} point = { .y = 3, .x = 2 };

----------------------------------------------------------------------

>Comment By: Philipp Krause (spth)
Date: 2010-04-23 00:31

Message:
- Should the term "designation initializer" be used in place of "designated
initalizer"? The first term is the one used in the C standard, while the
second oine is used in the rationale.

- Does the standard mandate that the initializations occour in a given
order? E.g. we have a volatile struct, inilialized using a designation
initalizer that lists the second member before the second do we have to
really initialize the second member first? Verse 1670-1672 seems to suggest
so to me (who doesn't really know anything about designation
initializers).

- The has a comment "If this is a hole, substitute an appropriate
initializer." Unless the object is static, can we increase efficiency by
not doing the initialization for these holes instead of initializing them
to 0?

Philipp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

[sdcc-devel] C99 Designated Initializer support (complete patch)

[C. Scott Ananian <cscott@li...>]

Here's a complete & tested patch for C99 "designated initializer"
support, against SVN HEAD.
This is feature request 2991122:
  https://sourceforge.net/tracker/?func=detail&aid=2991122&group_id=599&atid=350599

Enjoy!
 --scott

-- 
        (http://cscott.net)

[sdcc-devel] [ sdcc-Feature Requests-2991122 ] C99 designated initializer support

[SourceForge.net <noreply@so...>]

Feature Requests item #2991122, was opened at 2010-04-22 17:39
Message generated for change (Tracker Item Submitted) made by cananian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: C. Scott Ananian (cananian)
Assigned to: Nobody/Anonymous (nobody)
Summary: C99 designated initializer support

Initial Comment:
Add support for C99 "designated initializers", like:

struct {
   int x, y;
} point = { .y = 3, .x = 2 };

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=2991122&group_id=599

Re: [sdcc-devel] C99 Designated Initializer support (1st patch)

[Philipp Klaus Krause <pkk@sp...>]

Am 22.04.2010 02:36, schrieb C. Scott Ananian:
> On Wed, Apr 21, 2010 at 5:04 PM, C. Scott Ananian<cscott@...>  wrote:
>> code I'm writing much more straight-forward.  So here's the first
>> (incomplete!) patch -- this just adds support to the grammar, doesn't
>> do anything with the designators yet.
>
> Here's a second version of patch; it does designated initializers for arrays.
>    --scott

Thanks. IMO completing C support is an important task in sdcc 
development, and every bit towards that goal helps.

Philipp

Re: [sdcc-devel] C99 Designated Initializer support (1st patch)

[C. Scott Ananian <cscott@li...>]

On Wed, Apr 21, 2010 at 5:04 PM, C. Scott Ananian <cscott@...> wrote:
> code I'm writing much more straight-forward.  So here's the first
> (incomplete!) patch -- this just adds support to the grammar, doesn't
> do anything with the designators yet.

Here's a second version of patch; it does designated initializers for arrays.
  --scott

-- 
        (http://cscott.net)

[sdcc-devel] C99 Designated Initializer support (1st patch)

[C. Scott Ananian <cscott@li...>]

Adding designated initializer support would make the USB descriptor
code I'm writing much more straight-forward.  So here's the first
(incomplete!) patch -- this just adds support to the grammar, doesn't
do anything with the designators yet.

Any initial comments?  Anyone else working on this?  Is there already
a bug/feature request for this?
 --scott

-- 
        (http://cscott.net)

[sdcc-devel] [ sdcc-Bugs-2989562 ] stack integrity error after loop

[SourceForge.net <noreply@so...>]

Bugs item #2989562, was opened at 2010-04-19 13:39
Message generated for change (Tracker Item Submitted) made by salm2079
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2989562&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mcs51(8051) target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SteveA (salm2079)
Assigned to: Nobody/Anonymous (nobody)
Summary: stack integrity error after loop

Initial Comment:
Build of test code has push at top of loop but pop only occurs after loop terminates. Each iteration of loop pushes extra bytes.
Loop test includes a mask which was part of original code. Without masking operation the assembled code is correct and also code
built with version 2.8.0 #5117 (Jan 20 2009) (UNIX)
sdcc --version
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Aug 15 2009) (UNIX)
sdcc --Werror -mmcs51 --model-large  -c average.c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2989562&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986676 ] ucz80 fails to run z80 regtests on Solaris SPARC platform

[SourceForge.net <noreply@so...>]

Bugs item #2986676, was opened at 2010-04-13 21:17
Message generated for change (Comment added) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986676&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Simulator
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Borut Ražem (borutr)
>Assigned to: Borut Ražem (borutr)
Summary: ucz80 fails to run z80 regtests on Solaris SPARC platform

Initial Comment:
ucz80 simulator fails to execute the following regression tests on Solaris sparc platform with "Cpu Limit Exceeded - core dumped":
bp.c, bug-467035.c, bug-927659.c, bug1908493.c, driverstruct.c, float_single.c, float_trans.c, funptrs.c, memory.c, regtrack.c, snprintf.c and switch.c.

The z80 regression tests pass with rrz80 simulator.

Borut


----------------------------------------------------------------------

>Comment By: Borut Ražem (borutr)
Date: 2010-04-14 16:20

Message:
Fixed in svn revision #5812.

Borut

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986676&group_id=599

[sdcc-devel] [ sdcc-Webdocs-2986975 ] New Link for SDCC

[SourceForge.net <noreply@so...>]

Webdocs item #2986975, was opened at 2010-04-14 09:37
Message generated for change (Tracker Item Submitted) made by igorbipom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536150&aid=2986975&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Igor Slepchenkov (igorbipom)
Assigned to: Nobody/Anonymous (nobody)
Summary: New Link for SDCC

Initial Comment:
Hello

I want to ask you to announce the free IDE for SDCC compiler on your Links page.
I think this IDE will be useful for SDCC users

The link to the page dedicated to this product is:
http://www.bipom.com/products/us/319513.html

This is ready-to-use package which installs MicroIDE software (free IDE software to manage SDCC projects) and SDCC compiler.
MicroIDE is already configured to work together with SDCC.

The link to download package is:
http://www.bipom.com/sdcc_down.php

This product is free.

Thank you
Igor Slepchenkov
BiPOM Electronics, Inc.
 http://www.bipom.com
igor@...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536150&aid=2986975&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986827 ] 2.9.0 pointer of pointer bug

[SourceForge.net <noreply@so...>]

Bugs item #2986827, was opened at 2010-04-13 23:00
Message generated for change (Tracker Item Submitted) made by heidyalphs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986827&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mcs51(8051) target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: JeonIckSeong (heidyalphs)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.9.0 pointer of pointer bug

Initial Comment:
Hi,
2.9.0 ( maybe version greater than 2.5.0) has bug !!
FreeRTOS on 8051 platform file list.c 
function void vListInsertEnd( xList *pxList, xListItem *pxNextListItem)

pxIndex->pxNext->pxPrevious = (volatile xListItem *) pxNewListItem;

I guess pointer of pointer access has bug.

FreeRTOS (6.0.4) is successfully compiled and run OK wit sdcc 2.5.0.
but with 2.9.0 , it fail to run.
compile option :
 --less-pedantic --xram-size 4096 --no-peep --int-long-reent --float-reent --stack-auto --data-loc 0x8 --iram-size 0x80

IckSeong, Jeon
isjeon@...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986827&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986039 ] bit operations with wrong value in W register

[SourceForge.net <noreply@so...>]

Bugs item #2986039, was opened at 2010-04-12 14:10
Message generated for change (Comment added) made by jimatjtan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic14 target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Paris (jimatjtan)
Assigned to: Nobody/Anonymous (nobody)
Summary: bit operations with wrong value in W register

Initial Comment:
Attached code miscompiles on pic14.
sdcc -v:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Jan 10 2010) (UNIX)

compile with:
sdcc --std-c89 -mpic14 -p16f628a --opt-code-speed -c -o bug.o bug.c

In the .lst file, you can see four occurances like this one:

               00192 ;       .line   11; "bug.c"     RB6 = (c & 8) ? 1 : 0;
001E 0000 0000 00193         BANKSEL r0x1001
0020 0C00      00194         RRF     r0x1001,W
0021 1803      00195         BTFSC   STATUS,0
0022 2800      00196         GOTO    _00001_DS_
0023 0000 0000 00197         BANKSEL _PORTB_bits
0025 1300      00198         BCF     _PORTB_bits,6
0026           00199 _00001_DS_
0026 1C03      00200         BTFSS   STATUS,0
0027 2800      00201         GOTO    _00002_DS_
0028 0000 0000 00202         BANKSEL _PORTB_bits
002A 1700      00203         BSF     _PORTB_bits,6
002B           00204 _00002_DS_

but the "W" register (used in "RRF r0x1001,W") is a stale value, in this case 0x7B.


----------------------------------------------------------------------

Comment By: Jim Paris (jimatjtan)
Date: 2010-04-13 16:07

Message:
Sorry for the misdiagnosis, been dealing with too many assembly language
architectures lately :)
Your description sounds right and the workaround does the right thing. 
Thanks for looking into it.

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2010-04-12 18:28

Message:
OK, I see the problem now:

RB6 = (c & 8) ? 1 : 0;

is handled incorrectly (also for c&4, c&2, and c&1). Instead of implicitly
doing

RB6 = (0 != (c & 8)) ? 1 : 0;

sdcc executes

struct {
   uint8_t b0:1;
} temp;
temp.b0 = (c & 8); // THIS ALWAYS CLEARS temp.b0
RB6 = ((uint8_t)temp.b0) ? 1: 0;

by mistaking the logic bit test on bit 3 for an assignment to a bitfield
of width 1, for which only bit 0 of the expression is relevant...

As a workaround, you can use

RB6 = (0 != (c & 8)) ? 1 : 0;

I'll try to fix this.

Best regards,
Raphael

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2010-04-12 17:02

Message:
I do not see the problem: "RRF r0x1001, W" does not READ W at all -- it
overwrites W with "r0x1001 >> 1" and updates STATUS, extracting the least
signicant bit of r0x1001 (prior to shifting).
Could you give any more details? Observed vs. expected output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986676 ] ucz80 fails to run z80 regtests on Solaris SPARC platform

[SourceForge.net <noreply@so...>]

Bugs item #2986676, was opened at 2010-04-13 21:17
Message generated for change (Tracker Item Submitted) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986676&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Simulator
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Borut Ražem (borutr)
Assigned to: Nobody/Anonymous (nobody)
Summary: ucz80 fails to run z80 regtests on Solaris SPARC platform

Initial Comment:
ucz80 simulator fails to execute the following regression tests on Solaris sparc platform with "Cpu Limit Exceeded - core dumped":
bp.c, bug-467035.c, bug-927659.c, bug1908493.c, driverstruct.c, float_single.c, float_trans.c, funptrs.c, memory.c, regtrack.c, snprintf.c and switch.c.

The z80 regression tests pass with rrz80 simulator.

Borut


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986676&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986039 ] bit operations with wrong value in W register

[SourceForge.net <noreply@so...>]

Bugs item #2986039, was opened at 2010-04-12 18:10
Message generated for change (Comment added) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic14 target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Paris (jimatjtan)
Assigned to: Nobody/Anonymous (nobody)
Summary: bit operations with wrong value in W register

Initial Comment:
Attached code miscompiles on pic14.
sdcc -v:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Jan 10 2010) (UNIX)

compile with:
sdcc --std-c89 -mpic14 -p16f628a --opt-code-speed -c -o bug.o bug.c

In the .lst file, you can see four occurances like this one:

               00192 ;       .line   11; "bug.c"     RB6 = (c & 8) ? 1 : 0;
001E 0000 0000 00193         BANKSEL r0x1001
0020 0C00      00194         RRF     r0x1001,W
0021 1803      00195         BTFSC   STATUS,0
0022 2800      00196         GOTO    _00001_DS_
0023 0000 0000 00197         BANKSEL _PORTB_bits
0025 1300      00198         BCF     _PORTB_bits,6
0026           00199 _00001_DS_
0026 1C03      00200         BTFSS   STATUS,0
0027 2800      00201         GOTO    _00002_DS_
0028 0000 0000 00202         BANKSEL _PORTB_bits
002A 1700      00203         BSF     _PORTB_bits,6
002B           00204 _00002_DS_

but the "W" register (used in "RRF r0x1001,W") is a stale value, in this case 0x7B.


----------------------------------------------------------------------

>Comment By: Raphael Neider (tecodev)
Date: 2010-04-12 22:28

Message:
OK, I see the problem now:

RB6 = (c & 8) ? 1 : 0;

is handled incorrectly (also for c&4, c&2, and c&1). Instead of implicitly
doing

RB6 = (0 != (c & 8)) ? 1 : 0;

sdcc executes

struct {
   uint8_t b0:1;
} temp;
temp.b0 = (c & 8); // THIS ALWAYS CLEARS temp.b0
RB6 = ((uint8_t)temp.b0) ? 1: 0;

by mistaking the logic bit test on bit 3 for an assignment to a bitfield
of width 1, for which only bit 0 of the expression is relevant...

As a workaround, you can use

RB6 = (0 != (c & 8)) ? 1 : 0;

I'll try to fix this.

Best regards,
Raphael

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2010-04-12 21:02

Message:
I do not see the problem: "RRF r0x1001, W" does not READ W at all -- it
overwrites W with "r0x1001 >> 1" and updates STATUS, extracting the least
signicant bit of r0x1001 (prior to shifting).
Could you give any more details? Observed vs. expected output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986039 ] bit operations with wrong value in W register

[SourceForge.net <noreply@so...>]

Bugs item #2986039, was opened at 2010-04-12 18:10
Message generated for change (Comment added) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic14 target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Paris (jimatjtan)
Assigned to: Nobody/Anonymous (nobody)
Summary: bit operations with wrong value in W register

Initial Comment:
Attached code miscompiles on pic14.
sdcc -v:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Jan 10 2010) (UNIX)

compile with:
sdcc --std-c89 -mpic14 -p16f628a --opt-code-speed -c -o bug.o bug.c

In the .lst file, you can see four occurances like this one:

               00192 ;       .line   11; "bug.c"     RB6 = (c & 8) ? 1 : 0;
001E 0000 0000 00193         BANKSEL r0x1001
0020 0C00      00194         RRF     r0x1001,W
0021 1803      00195         BTFSC   STATUS,0
0022 2800      00196         GOTO    _00001_DS_
0023 0000 0000 00197         BANKSEL _PORTB_bits
0025 1300      00198         BCF     _PORTB_bits,6
0026           00199 _00001_DS_
0026 1C03      00200         BTFSS   STATUS,0
0027 2800      00201         GOTO    _00002_DS_
0028 0000 0000 00202         BANKSEL _PORTB_bits
002A 1700      00203         BSF     _PORTB_bits,6
002B           00204 _00002_DS_

but the "W" register (used in "RRF r0x1001,W") is a stale value, in this case 0x7B.


----------------------------------------------------------------------

>Comment By: Raphael Neider (tecodev)
Date: 2010-04-12 21:02

Message:
I do not see the problem: "RRF r0x1001, W" does not READ W at all -- it
overwrites W with "r0x1001 >> 1" and updates STATUS, extracting the least
signicant bit of r0x1001 (prior to shifting).
Could you give any more details? Observed vs. expected output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

[sdcc-devel] [ sdcc-Bugs-2986039 ] bit operations with wrong value in W register

[SourceForge.net <noreply@so...>]

Bugs item #2986039, was opened at 2010-04-12 14:10
Message generated for change (Tracker Item Submitted) made by jimatjtan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic14 target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Paris (jimatjtan)
Assigned to: Nobody/Anonymous (nobody)
Summary: bit operations with wrong value in W register

Initial Comment:
Attached code miscompiles on pic14.
sdcc -v:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Jan 10 2010) (UNIX)

compile with:
sdcc --std-c89 -mpic14 -p16f628a --opt-code-speed -c -o bug.o bug.c

In the .lst file, you can see four occurances like this one:

               00192 ;       .line   11; "bug.c"     RB6 = (c & 8) ? 1 : 0;
001E 0000 0000 00193         BANKSEL r0x1001
0020 0C00      00194         RRF     r0x1001,W
0021 1803      00195         BTFSC   STATUS,0
0022 2800      00196         GOTO    _00001_DS_
0023 0000 0000 00197         BANKSEL _PORTB_bits
0025 1300      00198         BCF     _PORTB_bits,6
0026           00199 _00001_DS_
0026 1C03      00200         BTFSS   STATUS,0
0027 2800      00201         GOTO    _00002_DS_
0028 0000 0000 00202         BANKSEL _PORTB_bits
002A 1700      00203         BSF     _PORTB_bits,6
002B           00204 _00002_DS_

but the "W" register (used in "RRF r0x1001,W") is a stale value, in this case 0x7B.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2986039&group_id=599

[sdcc-devel] [ sdcc-Support Requests-2983377 ] Header include provokes library build?

[SourceForge.net <noreply@so...>]

Support Requests item #2983377, was opened at 2010-04-07 11:31
Message generated for change (Comment added) made by ramey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2983377&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Robert Ramey (ramey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Header include provokes library build?

Initial Comment:
I'm compiling a file with the following command line:

c:\Projects\vario\gbparanoia>sdcc --stack-auto --vc -mgbz80 -IC:/gameboy/gbdk-3.0/include -IC:/SDCC-2.9/device/include -c -o part1.o part1.c    

The file part1.c refers to to function defined in the header file C:/gameboy/gbdk-3.0/include .  The file compiles fine - but then I get this message:

ar ruv C:/SDCC-2.9/lib/gbz80/gbz80.lib
ar: C:/SDCC-2.9/lib/gbz80/gbz80.lib: No such file or directory

Which suggests that it's trying to build the library (which isn't available yet. My make file includes an explicit link command.  How can I suppress or eliminate this error?

Also, so far I've been using a file gbdk.lib which consists of a list of object modules in the same directory.  This has worked very well for my purpose.  The documentation - I've just upgraded to 2.9.0 is a little unclear to me as to whether I can continue to use this method.

Robert Ramey



----------------------------------------------------------------------

Comment By: Robert Ramey (ramey)
Date: 2010-04-11 13:09

Message:
found one of my problems - FWIW here it is

I used the idiom

#define PARANOIA_BANK 1
...
#pragma bank PARANOIA_BANK 

which used to work in version 2.6 - now it doesn't

I traced this to an improvement in the pre-processor.  It no longer
expands macros is #pragma statements.  This turns out to be correct
behavior even though it is inconvenient in my case.  This was very
convenient as it permited me to make do

#include "banks.h"

which let me re-organize code into banks at one convenent place.

Finally, there is one last issue.  

#pragma bank X

creates a new area _X in my linker map.  So 

#pragma bank 1

creates an area _1 in my code.

Turns out if I use

#pragma bank CODE_1

gives me what I expect. I guess that now #pragma bank is equivalent to 
#pragma codeseg <name>

which is equivalent to --codeseg

which I suppose I can work with - though it's a pain to change all my make
and source files

Robert Ramey


----------------------------------------------------------------------

Comment By: Robert Ramey (ramey)
Date: 2010-04-10 14:40

Message:
Again that's for a helpful and timely response.

I re-introduced the -- switch by merging some code from the 2.6 version. 
This solved my problem.

Of course, now I have another one.  Here is the background.

a few years ago I embarked upon a project to make a flight instrument for
hanggliders which used the Gameboy as the user interface.  This project is
described at http://www.rrsd.com.

Of course I need to make software for my project and I started out using
lcc compiler and the gbdk from pascal felber.

The project kept growing.  I made numerous changes to the gbdk.

The project kept growing.  I needed to implement memory banking. I
enhanced the hardware to support it then discovered that support for
banking was "almost there".  I tweaked the sdcc 2.6 compiler to support it.
 After more effort than I really wanted to invest, I had things working
again.  Now I could run a program with upto 128K code into the gameboy
color!.

Last year, I decided to add "just one feature".  This a very trick
calculation of windspeed from GPS input which required extensive floating
point math. I managed to get the algorithm working on the PC - a lot more
effort than I had anticipated.  Then I tried to put it into the Gameboy. 
No luck.  The floating point code sin, cos, tan, atan, exp, log, etc
couldn't be made to fit.  Also it was excrutiatingly slow.  So I rewrote a
number of basic floating point functions  (fsadd, fssub, fsmul, fsdiv, etc)
in assembler and finally made things fit - and alot faster too.  I made
some basic tests and felt my code was working OK.

Alas, my program didnt' properly on my Gameboy simulator.  I knew that I
had to test my
floating point code independently.  I looked around and found
http://people.sc.fsu.edu/~burkardt/c_src/paranoia/paranoia.html.  I took
this program and compiled it with my system.  I had to re-organize it to
fit - in separate segments - but it does fit (barely) so now I have an
exhaustive test of the gameboy floating point implementation.

It failed the second test.  As I investigated, I found that the problem
for this failure was not in the library code (where I could fix it) but
rather in the compiler which generates some code for floating point
operations (e.g. x == 0.0f).  I downloaded the 2.9 compiler and generated
some code with it and found that it corrected at this problem.  So I
resolved to switch to the 2.9 version. I rebuilt it and here I am.

except for one thing. It doesn't generate the code I expect for bank
switching.  It's almost there.  It does generate the bank # in right place
(right after the call).  But whether I use the -bo ? or #praga bank ?
sytax, the code is not found in CODE_? but rather in the area beyond the
data.  I expect to see

CODE_1 ...

but rather I see

PARANOIA_BANK

I'll investigate this some more.

When I started this comment I had a question but now I forgot what it was.
 Either making this comment answered the question for me (often happens) or
I just forget or wanted some empathy.

Robert Ramey



Then with some more effort got it loaded into the Gameboy.  This basically
entailed organizing code in the right memory banks.  Finally I was ready to
fire it up - only to discover th

----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2010-04-10 11:32

Message:
The -- switch was available only for z80 and gb targets, so it was removed
due the sdld unification and synchronization with asxxxx. Actually it is
still supported in the official 2.9.0 release, but it was removed later.

The .lnk file can be generated on the fly by the makefile by echoing each
line into it, including "echo $(OBJ) >> <*>.lnk". So you have to maintain
only the makefile.

The other possibility would be to re-introduce the -- switch, but it
should be available in asxxxx too, which will be a longer process, probably
not available in sdcc 3.0 release...

Borut

----------------------------------------------------------------------

Comment By: Robert Ramey (ramey)
Date: 2010-04-10 09:58

Message:
Thanks for your prompt and helpful response!

I traced the problem to the usage of the -- switch which was used to
specify that the linker arguments should be taken from the command line. 
It seems that this facility is no longer supported in 2.9.0

The raises the question as to how one can use the linker in a makefile. 
The arguments come from a make variable (e.g. OBJ=a.o b.o ..).  If I can't
use this in the command line - how can I pass that information to the
linker? I could create a *.lnk file and use the -c switch - but then I have
to maintain that and keep it in sync with the makefile - another source of
hard to fine build errors - not to mention the extra work.

What do you recommend?

Robert Ramey


----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2010-04-07 12:51

Message:
Header include doesn't provoke anything else then the header inclusion ;-)
To exactly see which subcommands are run by sdcc, you can use the -V
command line option:

sdcc -V --stack-auto --vc -mgbz80 -IC:/gameboy/gbdk-3.0/include
-IC:/SDCC-2.9/device/include -c -o part1.o part1.c

If I understand you well, you are executing sdcc from makefile, so it is
possible that there is a make rule (explicit or implicit), which tries to
build the library? How does your makefile look like?

Does the invocation of ar happen also if you run sdcc from command line
(not from makefile)?

Anyway, the gbz80.lib should exist, since is a part of the sdcc
installation. How did you install sdcc?

sdcc can use 3 library types: the "list of object modules" you mentioned,
libraries produced with the "sdcclib" utility and "ar" format libraries.
System libraries prior the 2.9.0 version were "list of object modules"
type, in version 2.9.0 they are "ar" format libraries.

Borut

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200599&aid=2983377&group_id=599