yakumoklesk(_en_)yahoo(_punto_)es escribió:
Hola Carlos. No sé cuándo me voy a poner, pero quiero meterme un día con el SDCC que
hace tiempo me bajé y con el que estuve trasteando, pero ahora me has dejado frío con
ese bug. Sabes si está reportado en source forge o están haciendo algo al respecto?
Podrías darme detalles de dicho bug y en qué condiciones exactas ocurren? Es muy
habitual? Podrías ponerme un sencillo ejemplo explicativo? No quisiera ponerme a trastear
y darme de bruces como siempre con algo que no le encuentro explicación y que al final
resulta ser un bug del programa.
Gracias.
Pues mira lo estoy discutiendolo en la lista de SDCC tambien, lo he
puesto varias veces pero es la primera que me hacen caso, casi nadie lo
usa con z80, casi todos es para PICs.
Pongo la conversacion completa:
--------------------------------------------------------------------------------------------------------------------------------------------------
On Saturday 13 August 2005 23:54, SD-Snatcher wrote:
Groepaz escribió:
> On Saturday 13 August 2005 20:23, Robert Ramey wrote:
>>I'm working on a program for the gameboy color - ~z80 similar cpu. The
>> sdcc compiler on the gameboy development site is quite old and in any
>> case I could not get it function in a reliable manner. It did seem to
>> show promise however and the sdcc compiler shown here seems much
>> evolved. Does it still support the gameboy z80 CPU? Is it suitable for
>> GB development?
>
> i have used sdcc to port contiki to the gameboy a while ago, worked
> halfway stable, with quite some bugs but still way better than the really
> old version in gbdk :)
> ftp://ftp.musoftware.de/pub/groepaz/cc65-portlib.zip contains the generic
> code i have used, including a few things taken from gbdk.
Hi
Do you had problems with 16 bit comparisons?, (For, If, etc)
i dont remember any specific problems....but i've written down some things
while they happened....
**** PreProcessor ****
- parse array in array initialization
workaround:
in an array, always put a komma after the last element
**** Compiler ****
* integers seem to work better than longs
* integers seem to work better than chars
note: 2) works with contiki cvs, suspecting
this bug is connected to the "register" keyword.
1)
- internal error when "char" is used as array index
workaround:
array indices should probably always be better casted to int
if index-variables are char
char i;
for(i=0;i<10;i++) x=a[(int)i];
[contiki:1.0,cvs ctk_menuitem_add]
[contiki:1.0,cvs switch_menu_item]
[contiki:1.0,cvs draw_menu]
2)
- internal error when global "char" is assigned
static unsigned char i;
n->x=i;
workaround (ugly):
static unsigned char i;
static int theval;
static unsigned char* theptr;
theval = i;
theptr=&n->x;
*theptr= theval;
[contiki:1.0 ctk_icon_add]
* structs seem to buggy
note: both 1) and 2) work with contiki cvs, suspecting
this bug is connected to the "register" keyword.
1)
struct ctk_menu *menu;
struct ctk_menu *m;
m->next = menu;
menu->next = NULL;
workaround(ugly):
struct ctk_menu *menu;
struct ctk_menu *m;
struct ctk_menu** mm;
mm = &m->next;
*mm = menu;
mm = &menu->next;
*mm = NULL;
[contiki:1.0 ctk_menu_add]
2)
register struct ctk_menu *menu;
char *title;
menu->next = NULL;
menu->title = title;
workaround(ugly):
register struct ctk_menu *menu;
char *title;
struct ctk_menu** mm;
char** mt;
mm=&menu->next;
*mm = NULL;
mt=&menu->title;
*mt = title;
[contiki:1.0 ctk_menu_new]
* function pointers
- internal error when using function pointer with arguments
p->s(x, y);
workaround:
pass arguments via global variables (attention, functions that were
before may become no more reentrant)
int a,b;
a = x;
b = y;
p->s();
[contiki:1.0,cvs ek_dispatcher]
* the register keyword is screwed
- internal error when assigning from/to a variable declared "register"
-> see above bugs
workaround:
do not use the register keyword :)
* the const keyword is screwed
* structs are screwed
- arrays in structs tend to cause problems
workaround:
none :(
however, putting arrays as last element(s) in a struct seems to
work better sometimes.
* variable parameter lists are knax0red
- again, problem with passing chars and char*
**** Assembler ****
**** Linker ****
- complains about multiple definition of symbols (functions) although
those have been declared "static" and appear in different modules (files)
workaround:
you must rename the symbols to use unique names.
[contiki:1.0,cvs]
-- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html
http://www.pokefinder.org http://ftp.pokefinder.org
------------------------------------------------------- SF.Net email is
Sponsored by the Better Software Conference & EXPO September 19-22, 2005
* San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________ Sdcc-user mailing list
Sdcc-user(_en_)lists(_punto_)sourceforge(_punto_)net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
-----------------------------------------------------------------------------------------------------------------------------------------------
Parece que el mayor problema en mi caso es el del uso int al contrario
de lo que parecen decir.
Pero lo curioso es que cuando uso CHARs solo como indices no tengo
problemas, los problemas me vienen cuando tengo ademas INTs por mi mismo
di con una solucion que es asignar los int a long antes de hacer un for
pero resulta que al principio iba bien pero se ve que si se hace muchas
con tanto codigo inutil al final algo estas perdiendo de vista y tambien
me falla: Aqui tienes como esta actualmente da grima de verlo y de hecho
no funciona, aunque en realida deberia hacerlo por que los valores al
entrar al for son validos para que se ejecute. De hecho he quitado
varios printf que estan en el codigo y que asi lo indican.
int i1;
int i2;
int i3;
int block_ini;
int block_fin;
-----> long itemp;
int pos_nick;
int pos_ident;
int pos_comm;
int pos_ult;
int pos_dest;
int pos_prim;
int num_esp;
int num_dosp;
......
case 86: /* VERSION */
strcpy(ctcpbuf,"NOTICE ");
itemp=pos_nick; <-------- Truco del
almendruco
pos_nick=itemp; <---------
itemp=pos_prim;
pos_prim=itemp;
for(i2=pos_prim+1;i2<pos_nick;i2++)
<------ Este for no se ejecuta y deberia hacerlo siempre que se pasa por
aqui, a causa de ello el programa (un cliente de IRC) no responde al
comando CTCP de VERSION.
{
tempchar[0]=((char*)0x8000)[i2];
strcat(ctcpbuf,tempchar);
}
strcat(ctcpbuf," :\1VERSION Internet
Relay Chat Client for InterNestor Lite 1.0 using C functions. Version:");
strcat(ctcpbuf,VERSION);
strcat(ctcpbuf," \1\n");
TCPSend(tcph, ctcpbuf,
strlen(ctcpbuf),1);
break;
Como lo tengo varios meses parado no me acuerdo al 100% pero creo que la
cosa venia de que aunque hubiese declarado el int como unsigned, de
alguna estraña manra adquiria un valor negativo (y por lo tanto no
entraba al for), asiganadolo a un long y luego volviendolo a recuperar
funcionaba, ahora de repente dejo de hacerlo.
Saludos, y voy a tocarlo esta tarde aver si saco algo en limpio con lo
que me ha mandado esta gente.
