EmbeddedRelated.com
Forums

C to assembly compiler - How do I handle this situation?

Started by Kris Neot July 4, 2005
"Joseph Power" <joepower@mindspring.com> wrote in message
news:9ilic1944643a6v15295co7fmh0fpqohas@4ax.com...
> On Mon, 4 Jul 2005 18:22:01 +0800 in comp.arch.embedded, "Kris Neot" > <Kris.Neot@hotmail.com> wrote: > > >My simple CPU will be designed to customly fit my decoding, thus
requiring a
> >custom > >instruction set. I need a compiler that can "take in my instruction set"
and
> >compile the > >RS decoding software (in generic C) into assembly codes. Is this
possible?
> > Here are some possibilities: > > http://sdcc.sourceforge.net/ Small Device C Compiler > http://gcc.gnu.org/ The GCC compiler > http://anyc.sourceforge.net/ Any C > http://www.cs.princeton.edu/software/lcc/ lcc, A Retargetable
Compiler for ANSI C
> http://www.bloodshed.net/c/smallc22.zip Small C Compiler > http://www.tendra.org/ The TenDRA
project
> > hope that helps > > Joe >
Thank you Joe, I will read them.
"Rich Webb" <bbew.ar@mapson.nozirev.ten> wrote in message
news:20mic1dmtvpb3d70i6g61q95df5isqdt0f@4ax.com...
> On Mon, 4 Jul 2005 18:22:01 +0800, "Kris Neot" <Kris.Neot@hotmail.com> > wrote: > > >My simple CPU will be designed to customly fit my decoding, thus
requiring a
> >custom > >instruction set. I need a compiler that can "take in my instruction set"
and
> >compile the > >RS decoding software (in generic C) into assembly codes. Is this
possible?
> > Yes. The Gnu compilers (gcc) have a generic front-end and a processor > specific back-end. > > If you don't want to tackle re-targeting a gcc cross-compiler, there are > other options. You could start from another small device compiller like > BDS C http://www.bdsoft.com/resources/bdsc.html or the Small Device C > Compiler http://sdcc.sourceforge.net/ and change the back-end to emit > your specific machine code. > > Or, go the lex/yacc route and write your own parser and generator. Level > of difficulty = high if you want to create a fully compliant C99 > compiler. Much lower if you can get away with a C-like language subset. > > -- > Rich Webb Norfolk, VA
Thank you Rich, your information is of much use to me.
"Guy Macon" <http://www.guymacon.com/> wrote in message
news:11ciqjc4vvm276f@corp.supernews.com...
> > > > Kris Neot wrote: > > >My simple CPU will be designed to customly fit my decoding, > >thus requiring a custom instruction set. I need a compiler > >that can "take in my instruction set" and compile the > >RS decoding software (in generic C) into assembly codes. > >Is this possible? > > It is possible, but not wise. Writing or adapting a compiler > is a lot of work, but the reward at the end is the ability to > turn any C program into an executable that runs on your chip. > If you only need one program, hire a human with the right skills > (or learn them yourself) and have him do the "compiling" by hand. > > I would also question the need for a custom instruction set. > Could you explain why you think that no standard architecture > will do the job for you? >
Yes, I am sure there is, but it's daunting job to fully implement an instruction set when some of them are not necessary.
Kris Neot wrote:
> "Guy Macon" <http://www.guymacon.com/> wrote in message > news:11ciqjc4vvm276f@corp.supernews.com... > >> >> >>Kris Neot wrote: >> >> >>>My simple CPU will be designed to customly fit my decoding, >>>thus requiring a custom instruction set. I need a compiler >>>that can "take in my instruction set" and compile the >>>RS decoding software (in generic C) into assembly codes. >>>Is this possible? >> >>It is possible, but not wise. Writing or adapting a compiler >>is a lot of work, but the reward at the end is the ability to >>turn any C program into an executable that runs on your chip. >>If you only need one program, hire a human with the right skills >>(or learn them yourself) and have him do the "compiling" by hand. >> >>I would also question the need for a custom instruction set. >>Could you explain why you think that no standard architecture >>will do the job for you? >> > > > Yes, I am sure there is, but it's daunting job to fully implement an > instruction set when some of them are not necessary.
Then how about implementing a Trap/SWI, on non-covered opcodes, so you can do them in SW, should you ever strike one. That allows a std tool flow, for whatever CPU you choose to subset, and you code to avoid the inefficent ones, but it is not a drop-dead if you do hit them. For the new opcodes, you can use Macros, or carefull ASM mapping. You could also look at Randall Hyde's High level Assembler. http://webster.cs.ucr.edu/AsmTools/HLA/index.html for a very good example, of what CAN be done in the space between vanilla assemblers, and Compilers. -jg
On Tue, 5 Jul 2005 09:25:03 +0800, Kris Neot wrote:

>"Mat Nieuwenhoven" <mnieuw@dontincludethis.zap.a2000.nl> wrote in message >news:zavrhjqbagvapyhqrguvfmncnay.ij4jd10.pminews@news.text.chello.nl... >> On Mon, 4 Jul 2005 18:22:01 +0800, Kris Neot wrote: >> >> >My simple CPU will be designed to customly fit my decoding, thus >requiring a >> >custom >> >instruction set. I need a compiler that can "take in my instruction set" >and >> >compile the >> >RS decoding software (in generic C) into assembly codes. Is this >possible? >> >> If I read this correctly, you have a C program that needs to be converted >to >> a new assembly language. Don't you also need an assembler? >> Anyway, it sounds like a fair amount of work. The OpenWatcom C/C++/Fortran >> compilers have a frontend and a (tighly coupled, no intermediate language) >> codegenerator, which outputs object code directly (not assembler). A new >code >> generator could be created, but it is not for the faint-hearted - expect a >> fair amount time studying the current implementations. If your assembly >looks >> like one of those for the x86, Dec Alpha, PPC or MIPS CPUs you have >something >> to start from. If you decide to extend OpenWatcom, visit the >'contributors' >> group at news.openwatcom.org >> >> Mat Nieuwenhoven >> >> > >Thank you Mat. I was aware that one can write an assembler in Perl or Tcl, >thus, it won't be a difficulty for me since the methodology is predictable >and >known to me. Compiler is all new to me. I think, my instruction set will be >a >subset of 8086 (all expanded to 32-bit wide), removing some instructions >like >RRC, etc, and invent something like 32-bit multiplier and xor, hardware look >up table (8b in/8b out), etc.
I read in your other posts that you're a hardware engineer. I suggest you stay away from Watcom then for this project, it is way too complicated to add a new CPU. I guess an experienced C programmer unfamiliar with Watcom would need many months to fully add a new hardware platform, and that is after it is available. Not worth it for a single project. Mat Nieuwenhoven

Mat Nieuwenhoven wrote:
> On Tue, 5 Jul 2005 09:25:03 +0800, Kris Neot wrote: > > >"Mat Nieuwenhoven" <mnieuw@dontincludethis.zap.a2000.nl> wrote in message > >news:zavrhjqbagvapyhqrguvfmncnay.ij4jd10.pminews@news.text.chello.nl... > >> ... The OpenWatcom C/C++/Fortran > >> compilers have a frontend and a (tighly coupled, no intermediate language) > >> codegenerator, which outputs object code directly (not assembler). A new > >code > >> generator could be created, but it is not for the faint-hearted ... > > I read in your other posts that you're a hardware engineer. I suggest you > stay away from Watcom then for this project, it is way too complicated to add > a new CPU. I guess an experienced C programmer unfamiliar with Watcom would > need many months to fully add a new hardware platform, and that is after it > is available. Not worth it for a single project.
lcc (cited above and designed to be easily retargetable) usually requires only modest work to build a new machine description, if that's the direction the OP decides upon. --Toby
> > Mat Nieuwenhoven
"Kris Neot" <Kris.Neot@hotmail.com> writes:

> > Ok, I am hardware engineer, much of my previous work in designing ASIC and > FPGA, > designing a 32-bit CPU that uses ARM instrctions is only a matter of time > for me.
Take some care with this part: ARM are pretty strict about what they consider to be breaches of their intellectual property. However, if you were to do your re-implementation based solely on the correct published document, then you would probably be in the clear. In particular, I suggest you avoid all the Thumb stuff without checking for patents.
> However > translating C into ARM codes is new to me and I would like to spend more > time on the > hardware part. Also, RS decoding isn't easy either. My question is, is it > likely that any > compiler allows limiting the choice of assembly codes?
You want to look at gcc for this. (It's been a while, but:) if you remove the instructions from the "md" (machine description) file, then it won't generate them. Conversely, if you add new instructions, you can add template-based matching to select when to use your new instructions. cheers, Rich. -- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml
On Tue, 05 Jul 2005 15:55:23 +0100, Rich Walker <rw@shadow.org.uk>
wrote:

>"Kris Neot" <Kris.Neot@hotmail.com> writes: > >> >> Ok, I am hardware engineer, much of my previous work in designing ASIC and >> FPGA, >> designing a 32-bit CPU that uses ARM instrctions is only a matter of time >> for me. > >Take some care with this part: ARM are pretty strict about what they >consider to be breaches of their intellectual property. However, if you >were to do your re-implementation based solely on the correct published >document, then you would probably be in the clear. In particular, I >suggest you avoid all the Thumb stuff without checking for patents.
As long as you do not try to sell the thing you have produced to anybody, there should be no problems of using patented designs in any country I know of. The principle with patents has traditionally been that by publishing your idea you get in exchange an exclusive _commercial_ access right to it. Paul