Loading ...
Sorry, an error occurred while loading the content.

Small Device C Compiler

Expand Messages
  • bill rowe
    http://embedded.ifmo.ru/sdk/sdk11/soft/sdcc/Dutta-121.pdf Fyi. Specifically targetted at 8 bit systems. It seems to focus on the harvard architecture(separate
    Message 1 of 11 , Sep 7, 2012
    • 0 Attachment
      http://embedded.ifmo.ru/sdk/sdk11/soft/sdcc/Dutta-121.pdf

      Fyi. Specifically targetted at 8 bit systems. It seems to focus on the harvard architecture(separate program and data addressing) and small ram constraints which are not 1802 issues but there is a z80 port which is more old-line micro. The article also talks about using general purpose registers for variables which, i think, would be key for the 1802.

      I'm going to have a better look when i get back to a real computer.

      Sent from my iPhone

      Sent from my iPhone

      [Non-text portions of this message have been removed]
    • Kevin
      SDCC is very interesting and promising. However, the 1802 architecture is very unique, and very unlike the 8051 and its derivatives. I m certain it would
      Message 2 of 11 , Sep 7, 2012
      • 0 Attachment
        SDCC is very interesting and promising. However, the 1802 architecture is very unique, and very unlike the 8051 and its derivatives. I'm certain it would require meticulous effort to create an SDCC project targeting the 1802. I'm not sure how one would go about handling the added keywords for the 8051, which means that code written for the 8051 (an others?) would require porting.

        --- In cosmacelf@yahoogroups.com, bill rowe <bill_rowe_ottawa@...> wrote:
        >
        >
        > http://embedded.ifmo.ru/sdk/sdk11/soft/sdcc/Dutta-121.pdf
        >
        > Fyi. Specifically targetted at 8 bit systems. It seems to focus on the harvard architecture(separate program and data addressing) and small ram constraints which are not 1802 issues but there is a z80 port which is more old-line micro. The article also talks about using general purpose registers for variables which, i think, would be key for the 1802.
        >
        > I'm going to have a better look when i get back to a real computer.
        >
        > Sent from my iPhone
        >
        > Sent from my iPhone
        >
        > [Non-text portions of this message have been removed]
        >
      • Agree
        ... I can t imagine how much really 8051 specific code you d be porting to the 1802 rather than porting normal C. I thought the article made it clear that the
        Message 3 of 11 , Sep 8, 2012
        • 0 Attachment
          --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@...> wrote:
          >
          > SDCC is very interesting and promising. However, the 1802 architecture is very unique, and very unlike the 8051 and its derivatives. I'm certain it would require meticulous effort to create an SDCC project targeting the 1802. I'm not sure how one would go about handling the added keywords for the 8051, which means that code written for the 8051 (an others?) would require porting.
          >

          I can't imagine how much really 8051 specific code you'd be porting to the 1802 rather than porting normal C. I thought the article made it clear that the 8051-ism (like Harvard-ish storage classes) were optional and not used on other architectures. Further, the intermediate representation is flexible enough to accommodate non-8051, MCU specific hardware features. SDCC has been ported both to PIC, Z-80 and 68hc11, so it's pretty clear this isn't an issue in practice.
        • Kevin
          I ve written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to
          Message 4 of 11 , Sep 9, 2012
          • 0 Attachment
            I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.

            --- In cosmacelf@yahoogroups.com, "Agree" <ken@...> wrote:
            >
            >
            >
            > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
            > >
            > > SDCC is very interesting and promising. However, the 1802 architecture is very unique, and very unlike the 8051 and its derivatives. I'm certain it would require meticulous effort to create an SDCC project targeting the 1802. I'm not sure how one would go about handling the added keywords for the 8051, which means that code written for the 8051 (an others?) would require porting.
            > >
            >
            > I can't imagine how much really 8051 specific code you'd be porting to the 1802 rather than porting normal C. I thought the article made it clear that the 8051-ism (like Harvard-ish storage classes) were optional and not used on other architectures. Further, the intermediate representation is flexible enough to accommodate non-8051, MCU specific hardware features. SDCC has been ported both to PIC, Z-80 and 68hc11, so it's pretty clear this isn't an issue in practice.
            >
          • Agree
            ... Maybe I m missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051
            Message 5 of 11 , Sep 13, 2012
            • 0 Attachment
              --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@...> wrote:
              >
              > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
              >

              Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
            • Andrew Wasson
              No, I think you re right.... I believe the original idea was to come up with a modern C compiler but the conversation has strayed. I personally think it s been
              Message 6 of 11 , Sep 13, 2012
              • 0 Attachment
                No, I think you're right....

                I believe the original idea was to come up with a modern C compiler but the conversation has strayed. I personally think it's been interesting but I'm not sure where we ended up because it's splintered into discussions about Tiny Basic and byte code as well as a little discussion down Forth & 8th avenues.

                I'm not sure why we aren't building on Ted Rossin's work with his C compiler: http://www.tedrossin.net46.net/Electronics/RCA/RCA.html#Compiler

                Andrew




                On 2012-09-13, at 5:46 PM, Agree wrote:

                >
                >
                > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@...> wrote:
                > >
                > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                > >
                >
                > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                >
                >




                [Non-text portions of this message have been removed]
              • Kevin
                ... Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let s say I have a nice algorithm which I
                Message 7 of 11 , Sep 14, 2012
                • 0 Attachment
                  --- In cosmacelf@yahoogroups.com, "Agree" <ken@...> wrote:
                  >
                  > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                  > >
                  > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                  > >
                  > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                  >

                  Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.

                  Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.

                  Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                • Andrew Wasson
                  I take it that is an argument not to pursue the SDCC Compiler for 1802 use? What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are
                  Message 8 of 11 , Sep 14, 2012
                  • 0 Attachment
                    I take it that is an argument not to pursue the SDCC Compiler for 1802 use?

                    What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are supported by the SDCC Compiler? They obviously don't have the 8051 internal ram and other goodies that you've taken advantage of for the your optimized algorithm yet the compiler supports them and people use it. I don't follow your line of thinking. Are you negating the compiler specifically for portability between 8051 and 1802 or do you have deeper concerns? Personally, I won't be writing code for 8051, I might write code for Z80, 6800, 6502, 1802, SX, PIC and Atmel though.

                    Thanks,
                    Andrew


                    On 2012-09-14, at 12:19 AM, Kevin wrote:

                    > --- In cosmacelf@yahoogroups.com, "Agree" <ken@...> wrote:
                    > >
                    > > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                    > > >
                    > > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                    > > >
                    > > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                    > >
                    >
                    > Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.
                    >
                    > Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.
                    >
                    > Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                    >
                    >




                    [Non-text portions of this message have been removed]
                  • Kevin
                    Not in the slightest. The SDCC compiler seems very mature and well done. Just saying that any specialization for one CPU makes things less portable if you ever
                    Message 9 of 11 , Sep 14, 2012
                    • 0 Attachment
                      Not in the slightest. The SDCC compiler seems very mature and well done. Just saying that any specialization for one CPU makes things less portable if you ever port code to the 1802.

                      I'd go with SDCC if anyone here has the time to wrap their head around it.

                      --- In cosmacelf@yahoogroups.com, Andrew Wasson <awasson@...> wrote:
                      >
                      > I take it that is an argument not to pursue the SDCC Compiler for 1802 use?
                      >
                      > What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are supported by the SDCC Compiler? They obviously don't have the 8051 internal ram and other goodies that you've taken advantage of for the your optimized algorithm yet the compiler supports them and people use it. I don't follow your line of thinking. Are you negating the compiler specifically for portability between 8051 and 1802 or do you have deeper concerns? Personally, I won't be writing code for 8051, I might write code for Z80, 6800, 6502, 1802, SX, PIC and Atmel though.
                      >
                      > Thanks,
                      > Andrew
                      >
                      >
                      > On 2012-09-14, at 12:19 AM, Kevin wrote:
                      >
                      > > --- In cosmacelf@yahoogroups.com, "Agree" <ken@> wrote:
                      > > >
                      > > > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                      > > > >
                      > > > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                      > > > >
                      > > > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                      > > >
                      > >
                      > > Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.
                      > >
                      > > Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.
                      > >
                      > > Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                      > >
                      > >
                      >
                      >
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    • Andrew Wasson
                      Oh,.. Ok, cool. It looks like a good place to start if we re not pursuing Ted s C compiler. I think I ll have a peek at the documentation. Andrew ... Andrew
                      Message 10 of 11 , Sep 14, 2012
                      • 0 Attachment
                        Oh,.. Ok, cool. It looks like a good place to start if we're not pursuing Ted's C compiler. I think I'll have a peek at the documentation.

                        Andrew






                        On 2012-09-14, at 12:46 AM, Kevin wrote:

                        > Not in the slightest. The SDCC compiler seems very mature and well done. Just saying that any specialization for one CPU makes things less portable if you ever port code to the 1802.
                        >
                        > I'd go with SDCC if anyone here has the time to wrap their head around it.
                        >
                        > --- In cosmacelf@yahoogroups.com, Andrew Wasson <awasson@...> wrote:
                        > >
                        > > I take it that is an argument not to pursue the SDCC Compiler for 1802 use?
                        > >
                        > > What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are supported by the SDCC Compiler? They obviously don't have the 8051 internal ram and other goodies that you've taken advantage of for the your optimized algorithm yet the compiler supports them and people use it. I don't follow your line of thinking. Are you negating the compiler specifically for portability between 8051 and 1802 or do you have deeper concerns? Personally, I won't be writing code for 8051, I might write code for Z80, 6800, 6502, 1802, SX, PIC and Atmel though.
                        > >
                        > > Thanks,
                        > > Andrew
                        > >
                        > >
                        > > On 2012-09-14, at 12:19 AM, Kevin wrote:
                        > >
                        > > > --- In cosmacelf@yahoogroups.com, "Agree" <ken@> wrote:
                        > > > >
                        > > > > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                        > > > > >
                        > > > > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                        > > > > >
                        > > > > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                        > > > >
                        > > >
                        > > > Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.
                        > > >
                        > > > Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.
                        > > >
                        > > > Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                        > > >
                        > > >
                        > >
                        > >
                        > >
                        > >
                        > > [Non-text portions of this message have been removed]
                        > >
                        >
                        >

                        Andrew Wasson | Luna Design
                        1651 West 15th Street,
                        North Vancouver BC., V7P 1N3
                        604 987-2850







                        [Non-text portions of this message have been removed]
                      • eight_bit_jdrose
                        Looks like an impressive effort. Need to dowload SDCC and tinker with it. That is my goal for the winter. Learn C as it applies to small device environments
                        Message 11 of 11 , Sep 14, 2012
                        • 0 Attachment
                          Looks like an impressive effort. Need to dowload SDCC and tinker with it. That is my goal for the winter. Learn C as it applies to small device environments like PIC, 6502, Z80, etc.

                          I never heard of an 8051 until I read this thread however I am somewhat familiar with the Z80. I noticed the compiler supports the Gameboy microprocessor as well. That is nifty.

                          Be very cool if SDCC supported the 1802. I know nothing about compiler design...the 1802 is so different from the current processors that it supports I wonder if it is even possible?



                          ------------------------------
                          On Fri, Sep 14, 2012 12:46 AM PDT Kevin wrote:

                          >Not in the slightest. The SDCC compiler seems very mature and well done. Just saying that any specialization for one CPU makes things less portable if you ever port code to the 1802.
                          >
                          >I'd go with SDCC if anyone here has the time to wrap their head around it.
                          >
                          >--- In cosmacelf@yahoogroups.com, Andrew Wasson <awasson@...> wrote:
                          >>
                          >> I take it that is an argument not to pursue the SDCC Compiler for 1802 use?
                          >>
                          >> What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are supported by the SDCC Compiler? They obviously don't have the 8051 internal ram and other goodies that you've taken advantage of for the your optimized algorithm yet the compiler supports them and people use it. I don't follow your line of thinking. Are you negating the compiler specifically for portability between 8051 and 1802 or do you have deeper concerns? Personally, I won't be writing code for 8051, I might write code for Z80, 6800, 6502, 1802, SX, PIC and Atmel though.
                          >>
                          >> Thanks,
                          >> Andrew
                          >>
                          >>
                          >> On 2012-09-14, at 12:19 AM, Kevin wrote:
                          >>
                          >> > --- In cosmacelf@yahoogroups.com, "Agree" <ken@> wrote:
                          >> > >
                          >> > > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                          >> > > >
                          >> > > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                          >> > > >
                          >> > > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                          >> > >
                          >> >
                          >> > Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.
                          >> >
                          >> > Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.
                          >> >
                          >> > Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                          >> >
                          >> >
                          >>
                          >>
                          >>
                          >>
                          >> [Non-text portions of this message have been removed]
                          >>
                          >
                          >


                          --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@...> wrote:
                          >
                          > Not in the slightest. The SDCC compiler seems very mature and well done. Just saying that any specialization for one CPU makes things less portable if you ever port code to the 1802.
                          >
                          > I'd go with SDCC if anyone here has the time to wrap their head around it.
                          >
                          > --- In cosmacelf@yahoogroups.com, Andrew Wasson <awasson@> wrote:
                          > >
                          > > I take it that is an argument not to pursue the SDCC Compiler for 1802 use?
                          > >
                          > > What about z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A processors that are supported by the SDCC Compiler? They obviously don't have the 8051 internal ram and other goodies that you've taken advantage of for the your optimized algorithm yet the compiler supports them and people use it. I don't follow your line of thinking. Are you negating the compiler specifically for portability between 8051 and 1802 or do you have deeper concerns? Personally, I won't be writing code for 8051, I might write code for Z80, 6800, 6502, 1802, SX, PIC and Atmel though.
                          > >
                          > > Thanks,
                          > > Andrew
                          > >
                          > >
                          > > On 2012-09-14, at 12:19 AM, Kevin wrote:
                          > >
                          > > > --- In cosmacelf@yahoogroups.com, "Agree" <ken@> wrote:
                          > > > >
                          > > > > --- In cosmacelf@yahoogroups.com, "Kevin" <kriceslo@> wrote:
                          > > > > >
                          > > > > > I've written lots of 8051 code which is optimized around the 8051 registers and internal storage architecture. It is entirely conceivable one might want to port code written for the 8051 to another architecture. Code specialized to a particular MCU would not be portable without refactoring.
                          > > > > >
                          > > > > Maybe I'm missing the point. People want all sorts of stupid things, like porting 8051 code to a 1802, presumably reimplementing all the other 8051 specific hardware (counters, timers, ports) that any 8051 applications uses along the way. But I thought the object of the exercise was the potential to have a modern, optimizing C compiler that could be retargeted to generate code for something like the 1802. SDCC, in theory, could be a place to start. If the requirement is porting 8051 code to the 1802, then by all means I'll ignore this thread.
                          > > > >
                          > > >
                          > > > Yes, you are missing the point. Useful code written for the 8051 does not imply 8051 counters, timers, and ports. Let's say I have a nice algorithm which I have developed--but optimized--for the 8051. As a programmer familiar with the 8051 I would look at using some of the 8051's internal RAM for fast storage. Since the SDCC compiler provides keywords to do this I take advantage of it.
                          > > >
                          > > > Now, I want to port my code to run on the 1802. Because my code uses 8051-specific keywords, I cannot just compile the same code for the 1802. I now am forced to refactor the entire algorithm for the 1802.
                          > > >
                          > > > Because SDCC provides 8051 specific features the code loses portability. That says nothing about whether SDCC would be a good C compiler for the 1802, just that you can't take SDCC code specialized to the 8051 and simply recompile for the 1802.
                          > > >
                          > > >
                          > >
                          > >
                          > >
                          > >
                          > > [Non-text portions of this message have been removed]
                          > >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.