Menu
▾
▴
sdcc-user
|
From: N. A. C. <nes...@gm...> - 2008-08-12 01:10:54
Attachments:
firstchess.c
|
Hi, all!! I'm new to SDCC. I'm getting the following error when porting an app from GCC: firstchess.c:499: error 25: Structure/Union expected left of '.->' at least it happens 10 times. I'm attaching the sources, so you can check them. Thanks!! -- Néstor +34 687 96 74 81 nes...@gm... |
|
From: Raphael N. <rn...@we...> - 2008-08-12 06:30:31
Attachments:
firstchess.c
|
Hi, > I'm new to SDCC. I'm getting the following error when porting an app from GCC: > > firstchess.c:499: error 25: Structure/Union expected left of '.->' > > at least it happens 10 times. > > I'm attaching the sources, so you can check them. Thanks!! You did read the warnings, did you? SDCC changed structures as function arguments into pointers to structures, but did not adapt the references to them... Not too clever, but it warned you... I attached a compiling variant of your source to guide you: * Do not pass structures around, only pointers to them (SDCC limitation?) * Do not assign structures to one another, use memcpy instead (SDCC limitation?) * Do not use scanf(), not in SDCC libraries, or write one of your own. Good luck, Raphael PS: Are you sure you want to play chess on a small/embedded device with probably tight memory constraints (HIST hist[6000]; int piece[64]; int color[64]; char s[256]; MOVE movebuf[200];)?!? |
|
From: N. A. C. <nes...@gm...> - 2008-08-12 11:29:42
|
Thanks!! You were *very* fast. 2008/8/12 Raphael Neider <rn...@we...>: > Hi, > >> I'm new to SDCC. I'm getting the following error when porting an app from >> GCC: >> >> firstchess.c:499: error 25: Structure/Union expected left of '.->' >> >> at least it happens 10 times. >> >> I'm attaching the sources, so you can check them. Thanks!! > > You did read the warnings, did you? > SDCC changed structures as function arguments into pointers to structures, > but did not adapt the references to them... Not too clever, but it warned > you... I didn't realize, sorry. Now, I understand. :-) > > I attached a compiling variant of your source to guide you: > * Do not pass structures around, only pointers to them > (SDCC limitation?) > * Do not assign structures to one another, use memcpy instead > (SDCC limitation?) > * Do not use scanf(), not in SDCC libraries, or write one of your own. > > Good luck, > Raphael > > PS: Are you sure you want to play chess on a small/embedded device with > probably tight memory constraints (HIST hist[6000]; int piece[64]; int > color[64]; char s[256]; MOVE movebuf[200];)?!? The idea is to make a little board to play against it. And obviously, a normal processor would be too big to deal with (think about a Motherboard, memory and so on). We thought that we could use several microcontrollers to achieve parallel processing for the board, with very low energy drain. It wouldn't be so difficult, because chess is easily parallelizable. But, for now, we are trying with just one microcontroller, and a very basic chess program. This is just for fun, not for business, so we have plenty of time :-) If you know chess, you have probably realized that an opening book would be very helpful. We hope we will be able to attach some kind of memory (maybe CFlash) to the PIC, so it will be able to store a book, and maybe even some more useful data. Some kind of (faster) memory for hash tables and even for storing the game history would be nice, as you can imagine! But our main goal now is to build some application to test the PIC, load into it, and define how the interfaces will be (how can you input some movement, how will it output some other movement, how to communicate between PICS when multiprocessing a board, and, maybe the most difficult part, how to communicate with a real board with real pieces to detect them and evaluate the position to see if it's valid, and player is not cheating but following the game). If someone has some idea, please, let me know! > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > -- Néstor +34 687 96 74 81 nes...@gm... |
|
From: N. A. C. <nes...@gm...> - 2008-08-14 18:14:12
Attachments:
firstchess.tar.bz2
|
BTW, I have realized that I was compiling for the default target, not PIC16. Now, I'm getting some linker errors. I'm attaching the sources, you can test it just with # make I have commented out "puts" and "#include <assert.h>" and two assertions. But I still get the following: nestor@fijo-nestor:~/Desktop/chess/firstchess/pic16$ make sdcc firstchess.c -mpic16 -o firstChess message: using default linker script "/usr/share/gputils/lkr/18f452.lkr" warning: relocation of section "udata_firstchess_7" failed, relocating to a shared memory location error: linker script has no definition that matches the type of section "udata_firstchess_7" make: *** [all] Error 1 Any idea?? Thanks! 2008/8/12 Néstor Amigo Cairo <nes...@gm...>: > Thanks!! You were *very* fast. > > 2008/8/12 Raphael Neider <rn...@we...>: >> Hi, >> >>> I'm new to SDCC. I'm getting the following error when porting an app from >>> GCC: >>> >>> firstchess.c:499: error 25: Structure/Union expected left of '.->' >>> >>> at least it happens 10 times. >>> >>> I'm attaching the sources, so you can check them. Thanks!! >> >> You did read the warnings, did you? >> SDCC changed structures as function arguments into pointers to structures, >> but did not adapt the references to them... Not too clever, but it warned >> you... > > I didn't realize, sorry. Now, I understand. :-) >> >> I attached a compiling variant of your source to guide you: >> * Do not pass structures around, only pointers to them >> (SDCC limitation?) >> * Do not assign structures to one another, use memcpy instead >> (SDCC limitation?) >> * Do not use scanf(), not in SDCC libraries, or write one of your own. >> >> Good luck, >> Raphael >> >> PS: Are you sure you want to play chess on a small/embedded device with >> probably tight memory constraints (HIST hist[6000]; int piece[64]; int >> color[64]; char s[256]; MOVE movebuf[200];)?!? > > The idea is to make a little board to play against it. And obviously, > a normal processor would be too big to deal with (think about a > Motherboard, memory and so on). We thought that we could use several > microcontrollers to achieve parallel processing for the board, with > very low energy drain. It wouldn't be so difficult, because chess is > easily parallelizable. But, for now, we are trying with just one > microcontroller, and a very basic chess program. This is just for fun, > not for business, so we have plenty of time :-) > If you know chess, you have probably realized that an opening book > would be very helpful. We hope we will be able to attach some kind of > memory (maybe CFlash) to the PIC, so it will be able to store a book, > and maybe even some more useful data. Some kind of (faster) memory for > hash tables and even for storing the game history would be nice, as > you can imagine! > > But our main goal now is to build some application to test the PIC, > load into it, and define how the interfaces will be (how can you input > some movement, how will it output some other movement, how to > communicate between PICS when multiprocessing a board, and, maybe the > most difficult part, how to communicate with a real board with real > pieces to detect them and evaluate the position to see if it's valid, > and player is not cheating but following the game). > > If someone has some idea, please, let me know! > >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> >> > > > > -- > Néstor > +34 687 96 74 81 > nes...@gm... > -- Néstor +34 687 96 74 81 nes...@gm... -- Néstor +34 687 96 74 81 nes...@gm... |
|
From: Raphael N. <rn...@we...> - 2008-08-14 19:30:27
|
> BTW, I have realized that I was compiling for the default target, not > PIC16. Now, I'm getting some linker errors. I'm attaching the sources, > you can test it just with > # make > > I have commented out "puts" and "#include <assert.h>" and two assertions. > But I still get the following: > > nestor@fijo-nestor:~/Desktop/chess/firstchess/pic16$ make > sdcc firstchess.c -mpic16 -o firstChess You are compiling for the default pic18f452, which may or not be what you want. Select the desired target chip with -mpic16 -p18f6720 (replace 6720 with your device code). > message: using default linker script "/usr/share/gputils/lkr/18f452.lkr" > warning: relocation of section "udata_firstchess_7" failed, relocating > to a shared memory location > error: linker script has no definition that matches the type of > section "udata_firstchess_7" > make: *** [all] Error 1 > > Any idea?? Thanks! Yes: You are out of memory, and even if the device had enough memory, you fail to respect the data banking scheme of the PICs (BSR register). 1) You allocate the HIST hist[6000] array of 48000 bytes; the 18f452 only has 6 banks of 256 bytes ==> 1536 bytes of memory. 2) The 18f6720 has 15 banks of 256 bytes of memory ==> 3840 bytes, which is all the PIC architecture can address (16 bank is split into access bank and SFRs and not available for general use). 3) Even if your array was the only data structure and was only 257 bytes in size, this error would occur still. The data memory is organized in banks of 256 bytes; no single object can be longer than that (has to do with BANKSEL directives and compiler internal assumptions about each structure/array residing completely in a single bank). In short, you must cut down the hist structure to (say) HIST hist[32], or modify the .lkr file to create a huge bank to accommodate *only* this array (you would have to make sure that other objects allocated to that superbank do not cross 256-byte boundaries, which you cannot do ==> problem in the linker rather than the compiler). Even then I cannot guarantee that the array access works as expected in all cases (it should, but such a setup is highly unusual and untested). Such problems caused my initial doubts on playing chess on a microcontroller. Knowing that you want to use PICs, I cannot see how to solve them: Other devices (8051-derivatives) have external memory, which might be useful in this case (if they can address 64 kB of memory), but with PICs I can only think of manually attached memory via 2 or more 8 bit ports for addresses and data, SPI, ... Good luck, Raphael |
|
From: N. A. C. <nes...@gm...> - 2008-08-14 19:53:47
|
You put it very clear. The question now is if the PIC would at least be able to represent a board and make some moves without committing suicide. Maybe it could be used for some purpose: for example, to control positions of the pieces on the board, and things like that, then, a more powerful processor would be used for computations. But to start, I would prefer a PIC, since it's easier to program than other, more complex, solutions. Thanks!! If any more comments, please, let me know!! 2008/8/14 Raphael Neider <rn...@we...>: >> BTW, I have realized that I was compiling for the default target, not >> PIC16. Now, I'm getting some linker errors. I'm attaching the sources, >> you can test it just with >> # make >> >> I have commented out "puts" and "#include <assert.h>" and two assertions. >> But I still get the following: >> >> nestor@fijo-nestor:~/Desktop/chess/firstchess/pic16$ make >> sdcc firstchess.c -mpic16 -o firstChess > > You are compiling for the default pic18f452, which may or not be what > you want. Select the desired target chip with -mpic16 -p18f6720 (replace > 6720 with your device code). > >> message: using default linker script "/usr/share/gputils/lkr/18f452.lkr" >> warning: relocation of section "udata_firstchess_7" failed, relocating >> to a shared memory location >> error: linker script has no definition that matches the type of >> section "udata_firstchess_7" >> make: *** [all] Error 1 >> >> Any idea?? Thanks! > > Yes: You are out of memory, and even if the device had enough memory, > you fail to respect the data banking scheme of the PICs (BSR register). > > 1) You allocate the HIST hist[6000] array of 48000 bytes; the 18f452 > only has 6 banks of 256 bytes ==> 1536 bytes of memory. > > 2) The 18f6720 has 15 banks of 256 bytes of memory ==> 3840 bytes, which > is all the PIC architecture can address (16 bank is split into access > bank and SFRs and not available for general use). > > 3) Even if your array was the only data structure and was only 257 bytes > in size, this error would occur still. The data memory is organized in > banks of 256 bytes; no single object can be longer than that (has to do > with BANKSEL directives and compiler internal assumptions about each > structure/array residing completely in a single bank). > In short, you must cut down the hist structure to (say) HIST hist[32], > or modify the .lkr file to create a huge bank to accommodate *only* this > array (you would have to make sure that other objects allocated to that > superbank do not cross 256-byte boundaries, which you cannot do ==> > problem in the linker rather than the compiler). Even then I cannot > guarantee that the array access works as expected in all cases (it > should, but such a setup is highly unusual and untested). > > Such problems caused my initial doubts on playing chess on a > microcontroller. Knowing that you want to use PICs, I cannot see how to > solve them: Other devices (8051-derivatives) have external memory, which > might be useful in this case (if they can address 64 kB of memory), but > with PICs I can only think of manually attached memory via 2 or more 8 > bit ports for addresses and data, SPI, ... > > Good luck, > Raphael > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Néstor +34 687 96 74 81 nes...@gm... |
|
From: Raphael N. <rn...@we...> - 2008-08-14 20:30:06
|
> You put it very clear. The question now is if the PIC would at least
> be able to represent a board and make some moves without committing
> suicide. Maybe it could be used for some purpose: for example, to
> control positions of the pieces on the board, and things like that,
> then, a more powerful processor would be used for computations. But to
> start, I would prefer a PIC, since it's easier to program than other,
> more complex, solutions.
You could try to reduce the amount of data you store:
You have:
int piece[64]; // values 0..6
int color[64]; // values 0, 1, 6
typedef struct tag_MOVE {
int from, // values 0..63?
dest, // values 0..63?
type; // values 0..7
} MOVE;
/* For storing all moves of game */
typedef struct tag_HIST {
MOVE m;
int cap; // 0..6
} HIST;
That is 64x2 byte for piece and color and 8 byte per tag_HIST.
Using
/*
* Encode color as bit 3 of each entry, bits 0..2 denote the piece,
* 0 (or 15) is empty.
* A) 0: empty; 1..6: white; 9..14: black
* B) 0..5: white, 8..13: black, 15: empty
* I'd prefer A...
*
* #define PIECE(p) ((p) & 7)
* #define COLOR(p) (0 != ((p) & 8))
*
* p = piece[position];
* if (0 == piece) {
* empty;
* } else {
* // act on PIECE(p) of COLOR(p)
* }
*/
unsigned char piece[64];
// no color array
typedef struct tag_MOVE {
unsigned char from;
unsigned char dest;
unsigned char type:4;
unsigned char cap:4; // moved up from tag_HIST
} MOVE;
/* For storing all moves of game */
typedef struct tag_HIST {
MOVE m;
} HIST;
would be only 64x1 byte for piece and 3 byte per tag_HIST, allowing you
to keep a HIST hist[85] in a single data bank. It's not 6000, but for a
start... And by using accessor functions you could instantiate 1 <= N <=
8 (or so) of these arrays and access one of them at (INDEX div N),
basing the selection on (INDEX mod N) either via a pointer array or a
switch statement.
Happy coding,
Raphael
|
|
From: Arkadi S. <ar...@me...> - 2008-08-14 20:33:35
|
Néstor Amigo Cairo wrote: > start, I would prefer a PIC, since it's easier to program than other, > more complex, solutions. AVR should be also simple to program, but the architecture is more sane than PIC and AVR-GCC is more mature compiler. With the board like this http://olimex.com/dev/avr-tlcd-128.html you're all set. |
|
From: Philipp K. K. <pk...@sp...> - 2008-08-14 21:11:38
|
Néstor Amigo Cairo schrieb: > [...] I would prefer a PIC, since it's easier to program than other, > more complex, solutions. Due to the obligatory bank switching stuff used in PICs IMO they are among the most difficult to program among the processors supported by sdcc. IMO the Z80 is a lot easier to program. Philipp |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X