Thanks!! You were *very* fast. 2008/8/12 Raphael Neider <[EMAIL PROTECTED]>: > 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 > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > -- Néstor +34 687 96 74 81 [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
