From: Kim L. <lu...@di...> - 2005-11-22 17:25:38
|
We are in need of an assembler and compiler for a new Freescale 16 bit 8 register processor called xgate. xgate is the second cpu on the new dual processor S12X device. The 68HC9S12XDP512 is an example of this device. I've got some questions: a) what is the state of the hc08 port ? What works and what doesn't ? b) Xgate is a 16 bit processor with 7 general purpose registers. Is sdcc suitable for this target ? c) The 68hc11/12/9S12 processors are all supported by gcc. What, if anything, does gcc do that sdcc doesn't ? d) The hc08 port appears to have elf output. Does that mean it could be used with gdb ? e) xgate is a risc processor. It looks quite a bit like a PIC. An assembler already exists. Written in perl nonetheless. Would you start with the PIC source or the HC08 source. We've started porting xgate in gcc, so we possibly have some source done. f) Is there a doc somewhere describing how to port sdcc to a new target ? Thanks in advance. -- Kim Lux, Diesel Research Inc. |
From: Bernhard H. <sdc...@be...> - 2005-11-23 21:13:09
|
> We are in need of an assembler and compiler for a new Freescale 16 bit 8 > register processor called xgate. xgate is the second cpu on the new > dual processor S12X device. The 68HC9S12XDP512 is an example of this > device. > > I've got some questions: > > a) what is the state of the hc08 port ? What works and what doesn't ? It passes sdcc's regression test, so IMHO it's quite good. Just give it a try. > b) Xgate is a 16 bit processor with 7 general purpose registers. Is > sdcc suitable for this target ? There has been an effort to port sdcc for the xa51. AFAIK it should be possible to port sdcc to a 16 bit processor. A big problem might be some complex opcodes, which require an early optimization. This will have a big impact on all optimization levels of sdcc. > c) The 68hc11/12/9S12 processors are all supported by gcc. What, if > anything, does gcc do that sdcc doesn't ? > > d) The hc08 port appears to have elf output. Does that mean it could be > used with gdb ? > > e) xgate is a risc processor. It looks quite a bit like a PIC. An > assembler already exists. Written in perl nonetheless. Would you start > with the PIC source or the HC08 source. We've started porting xgate in > gcc, > so we possibly have some source done. I don't know. You should be prepared to invest many, many time to finish and debug the port. The time required to evaluate your questions above is negligible compared to the time required to do the whole port. I'm afraid that you can't expect too much help from the developers. > f) Is there a doc somewhere describing how to port sdcc to a new > target ? There's just a 5 page long article from Sandeep Dutta in Circuit Cellar, which might help a little bit at the beginning. And for all the other questions: use the source, luke! Bernhard |
From: Kim L. <lu...@di...> - 2005-11-23 21:30:31
|
On Wed, 2005-11-23 at 22:12 +0100, Bernhard Held wrote: > And for all the other questions: > use the source, luke! Thats nice to say, but it falls apart in practice. <getting on soapbox...> Here is what I don't like about open source: a) There is no documentation b) there isn't enough commentary in the code to figure it out, without being thoroughly familiar with it and if you were then you wouldn't need the comments in the first place. c) past developers don't want to be bothered to go back into their code to help new developers. So... if open source developers want open source apps to flourish, ie be maintained, extended, utilized, something has to change. Don't think I am picking on the sdcc community when I state this. gcc isn't any better and is probably worse. <off the soapbox> See the two examples below. Q1: From /mcs51, gen.c. Please explain this structure. static char *rb1regs[] = { "b1_0","b1_1","b1_2","b1_3","b1_4","b1_5","b1_6","b1_7", "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7" Notice there is no comment regarding these. For the record, I emailed someone in the mcs51 port and he couldn't explain them either. It looks like an array of registers, but it leaves some out as far as I can tell. Are these real physical registers or psuedo registers ? Q2: what is the significance of this table ? What does it do ? Where is it used and why ? I can see it is a list of opcodes, with probably read and write parameters. What is "j" about ? And why is this table needed in the first place ? I suspect it would be used in an optimization scheme where one could look and see if the destination register of one instruction could be used as the source register of another instruction. But... I am totally guessing and nothing in the code tells me that. See the problem ? static mcs51opcodedata mcs51opcodeDataTable[] = { {"acall","j", "", "", ""}, {"add", "", "w", "rw", "r"}, {"addc", "", "rw", "rw", "r"}, {"ajmp", "j", "", "", ""}, {"anl", "", "", "rw", "r"}, {"cjne", "j", "w", "r", "r"}, {"clr", "", "", "w", ""}, {"cpl", "", "", "rw", ""}, {"da", "", "rw", "rw", ""}, {"dec", "", "", "rw", ""}, {"div", "", "w", "rw", ""}, {"djnz", "j", "", "rw", ""}, {"inc", "", "", "rw", ""}, {"jb", "j", "", "r", ""}, {"jbc", "j", "", "rw", ""}, {"jc", "j", "", "", ""}, {"jmp", "j", "", "", ""}, {"jnb", "j", "", "r", ""}, {"jnc", "j", "", "", ""}, {"jnz", "j", "", "", ""}, {"jz", "j", "", "", ""}, {"lcall","j", "", "", ""}, {"ljmp", "j", "", "", ""}, {"mov", "", "", "w", "r"}, {"movc", "", "", "w", "r"}, {"movx", "", "", "w", "r"}, {"mul", "", "w", "rw", ""}, {"nop", "", "", "", ""}, {"orl", "", "", "rw", "r"}, {"pop", "", "", "w", ""}, {"push", "", "", "r", ""}, {"ret", "j", "", "", ""}, {"reti", "j", "", "", ""}, {"rl", "", "", "rw", ""}, {"rlc", "", "rw", "rw", ""}, {"rr", "", "", "rw", ""}, {"rrc", "", "rw", "rw", ""}, {"setb", "", "", "w", ""}, {"sjmp", "j", "", "", ""}, {"subb", "", "rw", "rw", "r"}, {"swap", "", "", "rw", ""}, {"xch", "", "", "rw", "rw"}, {"xchd", "", "", "rw", "rw"}, {"xrl", "", "", "rw", "r"}, }; -- Kim Lux, Diesel Research Inc. |
From: Kim L. <lu...@di...> - 2005-11-23 21:46:14
|
BTW: in Eclipse, I can turn on the indexer and easily find all the places that a data element is used, like rb1regs below. I did so and found this: emitcode ("mov","%s,%s", rb1regs[sic->argreg+offset-5], aopGet (IC_LEFT (sic), offset,FALSE, FALSE)); Being able to easily find this sort of stuff helps immensely, but it is still much harder to figure it out from the undocumented code than it would be to read a one line description of what the structure is and how it works. We will try to give at least a brief comment in all our code on this sort of thing. Now I have to figure out the signficance of "sic->argreg+offset-5", specifically the offset and magic number 5. Probably something to do with being relative to PC or something like that. Again I am guessing without a comment. On Wed, 2005-11-23 at 14:30 -0700, Kim Lux wrote: > On Wed, 2005-11-23 at 22:12 +0100, Bernhard Held wrote: > > And for all the other questions: > > use the source, luke! > > Thats nice to say, but it falls apart in practice. > > <getting on soapbox...> > > Here is what I don't like about open source: > > a) There is no documentation > b) there isn't enough commentary in the code to figure it out, without > being thoroughly familiar with it and if you were then you wouldn't need > the comments in the first place. > c) past developers don't want to be bothered to go back into their code > to help new developers. > > So... if open source developers want open source apps to flourish, ie be > maintained, extended, utilized, something has to change. > > Don't think I am picking on the sdcc community when I state this. gcc > isn't any better and is probably worse. > > <off the soapbox> > > > See the two examples below. > > Q1: From /mcs51, gen.c. Please explain this structure. > > static char *rb1regs[] = { > "b1_0","b1_1","b1_2","b1_3","b1_4","b1_5","b1_6","b1_7", > "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7" > > Notice there is no comment regarding these. For the record, I emailed > someone in the mcs51 port and he couldn't explain them either. It looks > like an array of registers, but it leaves some out as far as I can tell. > Are these real physical registers or psuedo registers ? > > Q2: what is the significance of this table ? What does it do ? Where > is it used and why ? > > I can see it is a list of opcodes, with probably read and write > parameters. What is "j" about ? And why is this table needed in the > first place ? I suspect it would be used in an optimization scheme > where one could look and see if the destination register of one > instruction could be used as the source register of another instruction. > But... I am totally guessing and nothing in the code tells me that. See > the problem ? > > static mcs51opcodedata mcs51opcodeDataTable[] = > { > {"acall","j", "", "", ""}, > {"add", "", "w", "rw", "r"}, > {"addc", "", "rw", "rw", "r"}, > {"ajmp", "j", "", "", ""}, > {"anl", "", "", "rw", "r"}, > {"cjne", "j", "w", "r", "r"}, > {"clr", "", "", "w", ""}, > {"cpl", "", "", "rw", ""}, > {"da", "", "rw", "rw", ""}, > {"dec", "", "", "rw", ""}, > {"div", "", "w", "rw", ""}, > {"djnz", "j", "", "rw", ""}, > {"inc", "", "", "rw", ""}, > {"jb", "j", "", "r", ""}, > {"jbc", "j", "", "rw", ""}, > {"jc", "j", "", "", ""}, > {"jmp", "j", "", "", ""}, > {"jnb", "j", "", "r", ""}, > {"jnc", "j", "", "", ""}, > {"jnz", "j", "", "", ""}, > {"jz", "j", "", "", ""}, > {"lcall","j", "", "", ""}, > {"ljmp", "j", "", "", ""}, > {"mov", "", "", "w", "r"}, > {"movc", "", "", "w", "r"}, > {"movx", "", "", "w", "r"}, > {"mul", "", "w", "rw", ""}, > {"nop", "", "", "", ""}, > {"orl", "", "", "rw", "r"}, > {"pop", "", "", "w", ""}, > {"push", "", "", "r", ""}, > {"ret", "j", "", "", ""}, > {"reti", "j", "", "", ""}, > {"rl", "", "", "rw", ""}, > {"rlc", "", "rw", "rw", ""}, > {"rr", "", "", "rw", ""}, > {"rrc", "", "rw", "rw", ""}, > {"setb", "", "", "w", ""}, > {"sjmp", "j", "", "", ""}, > {"subb", "", "rw", "rw", "r"}, > {"swap", "", "", "rw", ""}, > {"xch", "", "", "rw", "rw"}, > {"xchd", "", "", "rw", "rw"}, > {"xrl", "", "", "rw", "r"}, > }; > > > > -- Kim Lux, Diesel Research Inc. |
From: Bernhard H. <sdc...@be...> - 2005-11-23 21:47:37
|
> <getting on soapbox...> > > Here is what I don't like about open source: > > a) There is no documentation > b) there isn't enough commentary in the code to figure it out, without > being thoroughly familiar with it and if you were then you wouldn't need > the comments in the first place. > c) past developers don't want to be bothered to go back into their code > to help new developers. Yes, you're right. I fully agree :-) Accept it or forget it. > See the two examples below. Again: you'll have to find it out by yourself. Nobody (out of the active developers) knows the answers (don't you?). These are exactly the problems I'm facing when I'm hunting bugs. We all have to dig into the source and see how things work. Bernhard |
From: Kim L. <lu...@di...> - 2005-11-23 21:58:13
|
On Wed, 2005-11-23 at 22:47 +0100, Bernhard Held wrote: > > <getting on soapbox...> > > > > Here is what I don't like about open source: > > > > a) There is no documentation > > b) there isn't enough commentary in the code to figure it out, without > > being thoroughly familiar with it and if you were then you wouldn't need > > the comments in the first place. > > c) past developers don't want to be bothered to go back into their code > > to help new developers. > Yes, you're right. I fully agree :-) > Accept it or forget it. This is a stupid way to develop software. The open source community can't expect to flourish like this. I know of a certain open source project that has a certain component written by a certain expert that said component is full of bugs. And certain expert didn't document anything and nobody can understand his work. Which is probably why it is full of bugs in the first place. So... this component is holding up the whole project because when it crashes it takes down the application. All this trouble because the developer was too silly to put comments in code as he was writing it. Every read "Code Complete", "Writing Solid Code" or "Debugging the Development Process" ? I guess those rule don't apply in open source. > > See the two examples below. > Again: you'll have to find it out by yourself. Nobody (out of the active > developers) knows the answers (don't you?). These are exactly the problems > I'm facing when I'm hunting bugs. Ahhhh... that is the beauty of it. Lack of comments/documentation bites us all in the butt. The code we write is too complex to keep organized in our mind for a long time, even if we are the author. So... two years later when a bug needs to be fixed nobody knows what the original intent was. -- Kim Lux, Diesel Research Inc. |
From: Kim L. <lu...@di...> - 2005-11-24 07:02:47
|
On Wed, 2005-11-23 at 22:12 +0100, Bernhard Held wrote: > > b) Xgate is a 16 bit processor with 7 general purpose registers. Is > > sdcc suitable for this target ? > There has been an effort to port sdcc for the xa51. AFAIK it should > be > possible to port sdcc to a 16 bit processor. A big problem might be > some > complex opcodes, which require an early optimization. This will have a > big > impact on all optimization levels of sdcc. Could someone expand on this ? What exactly is meant by "complex opcode" ? Example ? -- Kim Lux, Diesel Research Inc. |
From: Jim P. <ji...@jt...> - 2005-11-23 22:07:58
|
> Q1: From /mcs51, gen.c. Please explain this structure. > > static char *rb1regs[] = { > "b1_0","b1_1","b1_2","b1_3","b1_4","b1_5","b1_6","b1_7", > "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7" I know nothing about the mc51 internals, but this clearly has to do with the support for parameters in bank 1: $ cvs annotate src/mcs51/gen.c | grep rb1regs | head -1 1.130 (sandeep 30-Jan-02): static char *rb1regs[] = { $ cvs log -r1.130 src/mcs51/gen.c date: 2002/01/30 04:44:24; author: sandeep; state: Exp; lines: +97 -82 Added support for --parms-in-bank1 > Notice there is no comment regarding these. Huh? Please get off your soapbox and spend your time more constructively learning how to use the tools of the project. If you need to know more information about a particular commit, in the case that a log message and corresponding diffs are insufficient, I'm sure a polite e-mail to the author of that line of code would tell you. > Q2: what is the significance of this table ? What does it do ? Where > is it used and why ? typedef struct mcs51opcodedata { char name[6]; char class[3]; char pswtype[3]; char op1type[3]; char op2type[3]; } See grep(1) or ctags(1) or etags(1) or a billion of other tools to find where it's used. -jim |
From: Kim L. <lu...@di...> - 2005-11-23 22:21:46
|
On Wed, 2005-11-23 at 17:07 -0500, Jim Paris wrote: > > Q1: From /mcs51, gen.c. Please explain this structure. > > > > static char *rb1regs[] = { > > "b1_0","b1_1","b1_2","b1_3","b1_4","b1_5","b1_6","b1_7", > > "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7" > > I know nothing about the mc51 internals, but this clearly has to do > with the support for parameters in bank 1: > > $ cvs annotate src/mcs51/gen.c | grep rb1regs | head -1 > 1.130 (sandeep 30-Jan-02): static char *rb1regs[] = { > > $ cvs log -r1.130 src/mcs51/gen.c > date: 2002/01/30 04:44:24; author: sandeep; state: Exp; lines: +97 -82 > Added support for --parms-in-bank1 > > > Notice there is no comment regarding these. > > Huh? Please get off your soapbox and spend your time more > constructively learning how to use the tools of the project. Sorry that I didn't think to look in etags ! Etags happen to work in this instance because this was a small check in. If this was part of the the original check in there would be a comment for this one feature of the code. A simple comment line like "For --parms-in-bank1" in the code would make the structure much more understandable. -- Kim Lux, Diesel Research Inc. |
From: Bernhard H. <sdc...@be...> - 2005-11-24 09:55:14
|
> > > <getting on soapbox...> > > > > > > Here is what I don't like about open source: > > > > > > a) There is no documentation > > > b) there isn't enough commentary in the code to figure it out, without > > > being thoroughly familiar with it and if you were then you wouldn't need > > > the comments in the first place. > > > c) past developers don't want to be bothered to go back into their code > > > to help new developers. > > Yes, you're right. I fully agree :-) > > Accept it or forget it. > > This is a stupid way to develop software. The open source community > can't expect to flourish like this. I know of a certain open source > project that has a certain component written by a certain expert that > said component is full of bugs. And certain expert didn't document > anything and nobody can understand his work. Which is probably why it > is full of bugs in the first place. So... this component is holding up > the whole project because when it crashes it takes down the application. > All this trouble because the developer was too silly to put comments in > code as he was writing it. > > Every read "Code Complete", "Writing Solid Code" or "Debugging the > Development Process" ? I guess those rule don't apply in open > source. > > > > See the two examples below. > > Again: you'll have to find it out by yourself. Nobody (out of the active > > developers) knows the answers (don't you?). These are exactly the problems > > I'm facing when I'm hunting bugs. > > Ahhhh... that is the beauty of it. Lack of comments/documentation bites > us all in the butt. The code we write is too complex to keep organized > in our mind for a long time, even if we are the author. So... two years > later when a bug needs to be fixed nobody knows what the original intent > was. It's high time that you understand, that neither me nor the rest of the active developers are responsible for the quality of (major parts of) the source. We didn't write it, we're just trying to maintain it. I can't change the way it is. We're definitely not responsible of the mistakes of the past. I'm not the right address for your complaints, they absolutely don't help here. Yes, they are even counterproductive. If it helps you feel free and contact Sandeep. You can tell here how brilliant you are and how stupid she was. Again: you can use open source for FREE. If you don't like what you get for FREE let it be. Your claims are bothering. If you're looking for help this is certainly the worst introduction I can think of. It's time for me to stop this thread and continue with some productive work, Bernhard |
From: Kim L. <lu...@di...> - 2005-11-24 15:35:56
|
Don't shoot me for complaining about the lack of comments in code. I'm the friggin messenger ! I'm the guy that decided to go ahead with a project in spite of the lack of comments in the code. If you want your sdcc project to flourish, you should be treating guys like me with kid gloves. I could port lcc to handle xgate and forget all about sdcc. Not only is the lcc code well documented, there is a book written about how it works. How many people do you think have considered doing something with an open source project and forgone their efforts because of the attitude so clearly displayed here yesterday ? I'm not the problem. I got 3 sympathy emails from frustrated developers after my post here yesterday. And I'll repeat that I find the sdcc code to be much better documented/organized than some other open source projects. What got this started was the flippant "use the source luke" comment. Source code is NOT self documenting and if the group can't be bothered to answer stupid newbie questions then new people aren't going to join their project. And the fact that some think this discussion was a waste of time CLEARLY illustrates wherein the problem lies: attitude. And just because the code is free doesn't change the situation. gcc is free too. The cost is irrelevant. If I made enemies, so be it. Sometimes good medicine tastes bad. The ironic thing about this situation is that the exchange started because I had taken the time to document something for developing sdcc further, my Porting HOWTO. The very people that said I should not be complaining about a lack of comments/documentation are hungry for the documentation I have developed ! Nobody contributes doc to the wiki, the AVR port goes unfinished and meanwhile gcc is reported to have a decent AVR port. Hmmmm.... Just to clarify, I am grateful to the people that have contributed to the sdcc project. I appreciate the effort it must have taken. But to be successful in the long term, the project needs more technical documentation so that outsiders can participate. For the record, I've received good off list support from a number of developers. For that I am grateful. -- Kim Lux, Diesel Research Inc. |
From: Scott D. <sc...@da...> - 2005-11-24 19:34:57
|
Hi All, Without entering into the fray of the argument, I'd just like to note that both Bernhard's and Kim's comments are legitimate. As experienced programmers I'm sure both of you have seen this situation before. In my experience I've found that when the objective complaints start becoming personal that it's time to step back, take a deep break and slow down. For the SDCC developers I suggest that you take Kim's comments as constructive criticism and ignore those particular comments that you perceive as personal. Especially ignore the guilt-by-association accusation. For Kim, I suggest that you use your experience with dealing with a loose knit of hobbyist programmers and tailor your questions and expectations accordingly. If you were working with say Clyde at Hi-Tech or Walter at Byte Craft and found their documentation to be commensurate with SDCC's then your complaints would be warranted. Both groups have something to gain here. If Kim can motivate a documentation effort that rivals professional C compilers then that'd be great. If SDCC can provide a base for the xgate processor then that'd be great too. When I started gpsim several years ago and saw some of the code that people contributed I was sometimes disappointed. But a friend of mine reminded me, " don't ever look a gift horse in the mouth." I think the same applies here - to all concerned parties! Scott > Don't shoot me for complaining about the lack of comments in code. I'm > the friggin messenger ! > > I'm the guy that decided to go ahead with a project in spite of the lack > of comments in the code. If you want your sdcc project to flourish, you > should be treating guys like me with kid gloves. I could port lcc to > handle xgate and forget all about sdcc. Not only is the lcc code well > documented, there is a book written about how it works. > > How many people do you think have considered doing something with an > open source project and forgone their efforts because of the attitude so > clearly displayed here yesterday ? I'm not the problem. I got 3 > sympathy emails from frustrated developers after my post here > yesterday. > > And I'll repeat that I find the sdcc code to be much better > documented/organized than some other open source projects. > > What got this started was the flippant "use the source luke" comment. > Source code is NOT self documenting and if the group can't be bothered > to answer stupid newbie questions then new people aren't going to join > their project. > > And the fact that some think this discussion was a waste of time CLEARLY > illustrates wherein the problem lies: attitude. > > And just because the code is free doesn't change the situation. gcc is > free too. The cost is irrelevant. > > If I made enemies, so be it. Sometimes good medicine tastes bad. The > ironic thing about this situation is that the exchange started because I > had taken the time to document something for developing sdcc further, my > Porting HOWTO. The very people that said I should not be complaining > about a lack of comments/documentation are hungry for the documentation > I have developed ! Nobody contributes doc to the wiki, the AVR port > goes unfinished and meanwhile gcc is reported to have a decent AVR port. > Hmmmm.... > > Just to clarify, I am grateful to the people that have contributed to > the sdcc project. I appreciate the effort it must have taken. But to > be successful in the long term, the project needs more technical > documentation so that outsiders can participate. > > For the record, I've received good off list support from a number of > developers. For that I am grateful. > > -- > Kim Lux, Diesel Research Inc. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Maarten B. <sou...@ds...> - 2005-11-25 00:01:12
|
> > f) Is there a doc somewhere describing how to port sdcc to a new > > target ? > There's just a 5 page long article from Sandeep Dutta in Circuit Cellar, which > might help a little bit at the beginning. That's great, but how is one to get that article? It's five years old and after looking around at Circuit Cellar's website I do not get the impression I can download it even if I were to subscribe now. |
From: Jesus Calvino-F. <Je...@ec...> - 2005-11-25 00:34:44
|
Hi Marteen, If you are a sdcc administrator, login to ssh.sourceforge.net, cd to /home/groups/s/sd/sdcc. I uploaded a pdf scan of the article there (Sandeep_article.pdf). For a limited time the article will be also available at http://www.ece.ubc.ca/~jesusc/Sandeep_article.pdf Jesus At 04:01 PM 11/24/2005, you wrote: > > > f) Is there a doc somewhere describing how to port sdcc to a new > > > target ? > > There's just a 5 page long article from Sandeep Dutta in Circuit > Cellar, which > > might help a little bit at the beginning. > >That's great, but how is one to get that article? It's five years old and >after looking around at Circuit Cellar's website I do not get the >impression I can download it even if I were to subscribe now. > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >sdcc-devel mailing list >sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Kim L. <lu...@di...> - 2005-11-25 01:15:12
|
At the end of this article, it says: "A complete table of the iCode operations that are supported by the compiler as well as an additional sample code listing are available on the Circuit Cellar website." Could I get the table od the iCode operations ? Where would it be ? I'm looking at that part of things in the code right now. -- Kim Lux, Diesel Research Inc. |
From: Jesus Calvino-F. <Je...@ec...> - 2005-11-25 04:12:54
|
ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2000/121/dutta.ZIP At 05:14 PM 11/24/2005, Lim Lux wrote: >At the end of this article, it says: > >"A complete table of the iCode operations that are supported by the >compiler as well as an additional sample code listing are available on >the Circuit Cellar website." > >Could I get the table od the iCode operations ? Where would it be ? >I'm looking at that part of things in the code right now. > >-- >Kim Lux, Diesel Research Inc. |
From: Kim L. <lu...@di...> - 2005-11-25 07:02:46
|
Thanks. On Thu, 2005-11-24 at 20:08 -0800, Jesus Calvino-Fraga wrote: > ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2000/121/dutta.ZIP > > At 05:14 PM 11/24/2005, Lim Lux wrote: > > >At the end of this article, it says: > > > >"A complete table of the iCode operations that are supported by the > >compiler as well as an additional sample code listing are available on > >the Circuit Cellar website." > > > >Could I get the table od the iCode operations ? Where would it be ? > >I'm looking at that part of things in the code right now. > > > >-- > >Kim Lux, Diesel Research Inc. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > -- Kim Lux, Diesel Research Inc. |