Sign in
Search hc11
Subscribe to hc11
Ads
Discussion Groups
Discussion Groups | M68HC11 | Compiler Port Collaboration
Technical discussions about Freescale Microcontrollers: M68HC11. (Freescale Semiconductor is a Subsidiary of Motorola).
Compiler Port Collaboration - Mike McCarty - Oct 25 14:42:00 2005
I see that there isn't a reasonable cheap compiler for the
'11 and '12. I realize that the '11 is nearly dead, but I
do use it, and would like a reasonable compiler for it,
as a hobby. IOW, no $$$. I've been using a port of Small C
I did several years ago, but I'm really missing structures
and unions from time to time. Having long ints would be nice
occasionally, as well.
I am aware of the GCC port, and have tried it a couple of
times. But GCC is "too big" for the '11, and results in
very inefficient code. I've been in contact with the owner
of C68 about possibly making it have a less machine dependent
back end, and we're getting close.
Anyone interested in collaborating on a back end for the '11
and '12? Making it work with the '12 might make it last a little
longer.
I've taken a stab at LCC, and it's also just a little bit "big"
for the '11, but would be willing to reconsider LCC if anyone
here feels it would be a better choice. In fact, I'm willing to
consider any alternative.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
'11 and '12. I realize that the '11 is nearly dead, but I
do use it, and would like a reasonable compiler for it,
as a hobby. IOW, no $$$. I've been using a port of Small C
I did several years ago, but I'm really missing structures
and unions from time to time. Having long ints would be nice
occasionally, as well.
I am aware of the GCC port, and have tried it a couple of
times. But GCC is "too big" for the '11, and results in
very inefficient code. I've been in contact with the owner
of C68 about possibly making it have a less machine dependent
back end, and we're getting close.
Anyone interested in collaborating on a back end for the '11
and '12? Making it work with the '12 might make it last a little
longer.
I've taken a stab at LCC, and it's also just a little bit "big"
for the '11, but would be willing to reconsider LCC if anyone
here feels it would be a better choice. In fact, I'm willing to
consider any alternative.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - BobG...@... - Oct 25 16:55:00 2005
In a message dated 10/25/05 2:43:36 P.M. Eastern Daylight Time,
Mike.McCarty@Mike... writes:
see that there isn't a reasonable cheap compiler for the
'11 and '12. I realize that the '11 is nearly dead, but I
do use it, and would like a reasonable compiler for it,
as a hobby. IOW, no $$$. =========================
Dont like the Imagecraft HC11 compiler? Pretty cheap. Only thing it doesnt
have is direct addressed vars [Non-text portions of this message have been removed]
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Mike McCarty - Oct 25 17:04:00 2005
BobGardner@BobG... wrote:
>
> In a message dated 10/25/05 2:43:36 P.M. Eastern Daylight Time,
> Mike.McCarty@Mike... writes:
>
> see that there isn't a reasonable cheap compiler for the
> '11 and '12. I realize that the '11 is nearly dead, but I
> do use it, and would like a reasonable compiler for it,
> as a hobby. IOW, no $$$. > =========================
> Dont like the Imagecraft HC11 compiler? Pretty cheap. Only thing it doesnt
> have is direct addressed vars
It's inexpensive, yes. I meant what I wrote, no $$$.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
>
> In a message dated 10/25/05 2:43:36 P.M. Eastern Daylight Time,
> Mike.McCarty@Mike... writes:
>
> see that there isn't a reasonable cheap compiler for the
> '11 and '12. I realize that the '11 is nearly dead, but I
> do use it, and would like a reasonable compiler for it,
> as a hobby. IOW, no $$$. > =========================
> Dont like the Imagecraft HC11 compiler? Pretty cheap. Only thing it doesnt
> have is direct addressed vars
It's inexpensive, yes. I meant what I wrote, no $$$.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - BobG...@... - Oct 25 17:59:00 2005
In a message dated 10/25/05 5:32:17 P.M. Eastern Daylight Time,
Mike.McCarty@Mike... writes:
It's inexpensive, yes. I meant what I wrote, no $$$.
========================
Maybe Richard Man will trade you something for the source to an old version.
Got anything a compiler writer guy would want? [Non-text portions of this message have been removed]
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Oliver Betz - Oct 26 4:50:00 2005
Mike McCarty <Mike.McCarty@Mike...> wrote:
> I am aware of the GCC port, and have tried it a couple of
> times. But GCC is "too big" for the '11, and results in
> very inefficient code. I've been in contact with the owner
Inefficient library functions, or poor optimizing at all?
"Too big" shouldn't be that problem today, IMHO more important is to
get a long-lived base which is easy to adapt.
I don't know how hard a GCC backend is to maintain, so I can't say
whether it's efficient to go ahead with it.
[...]
> I've taken a stab at LCC, and it's also just a little bit "big"
> for the '11, but would be willing to reconsider LCC if anyone
Indeed? AFAIK ICC is based on LCC.
Oliver
--
Oliver Betz, Muenchen
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
> I am aware of the GCC port, and have tried it a couple of
> times. But GCC is "too big" for the '11, and results in
> very inefficient code. I've been in contact with the owner
Inefficient library functions, or poor optimizing at all?
"Too big" shouldn't be that problem today, IMHO more important is to
get a long-lived base which is easy to adapt.
I don't know how hard a GCC backend is to maintain, so I can't say
whether it's efficient to go ahead with it.
[...]
> I've taken a stab at LCC, and it's also just a little bit "big"
> for the '11, but would be willing to reconsider LCC if anyone
Indeed? AFAIK ICC is based on LCC.
Oliver
--
Oliver Betz, Muenchen
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Mike McCarty - Oct 26 13:01:00 2005
Oliver Betz wrote:
> Mike McCarty <Mike.McCarty@Mike...> wrote: >>I am aware of the GCC port, and have tried it a couple of
>>times. But GCC is "too big" for the '11, and results in
>>very inefficient code. I've been in contact with the owner > Inefficient library functions, or poor optimizing at all?
Umm, have you ever done a GCC port? I did one for the Z8000,
and the presumptions GCC places on the underlying processor
are not satisfied by the 6811. So one ends up implementing
a virtual processor and emulating it.
For example, GCC presumes that any register can be added to
any other register. It also presumes that a 32 bit quantity
can be added to a register as an immediate.
That's why I say it results in inefficient code.
> "Too big" shouldn't be that problem today, IMHO more important is to
> get a long-lived base which is easy to adapt.
By "too big" I didn't mean that the compiler is too large. I mean it
presumes too much of the underlying processor. And that *is* important.
> I don't know how hard a GCC backend is to maintain, so I can't say
> whether it's efficient to go ahead with it.
GCC is very ambitious and very difficult to use. And not very well
documented, either. > [...] >>I've taken a stab at LCC, and it's also just a little bit "big"
>>for the '11, but would be willing to reconsider LCC if anyone > Indeed? AFAIK ICC is based on LCC.
Yes, I've exchanged e-mail a few times with the author. He also
used a virtual machine approach.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
> Mike McCarty <Mike.McCarty@Mike...> wrote: >>I am aware of the GCC port, and have tried it a couple of
>>times. But GCC is "too big" for the '11, and results in
>>very inefficient code. I've been in contact with the owner > Inefficient library functions, or poor optimizing at all?
Umm, have you ever done a GCC port? I did one for the Z8000,
and the presumptions GCC places on the underlying processor
are not satisfied by the 6811. So one ends up implementing
a virtual processor and emulating it.
For example, GCC presumes that any register can be added to
any other register. It also presumes that a 32 bit quantity
can be added to a register as an immediate.
That's why I say it results in inefficient code.
> "Too big" shouldn't be that problem today, IMHO more important is to
> get a long-lived base which is easy to adapt.
By "too big" I didn't mean that the compiler is too large. I mean it
presumes too much of the underlying processor. And that *is* important.
> I don't know how hard a GCC backend is to maintain, so I can't say
> whether it's efficient to go ahead with it.
GCC is very ambitious and very difficult to use. And not very well
documented, either. > [...] >>I've taken a stab at LCC, and it's also just a little bit "big"
>>for the '11, but would be willing to reconsider LCC if anyone > Indeed? AFAIK ICC is based on LCC.
Yes, I've exchanged e-mail a few times with the author. He also
used a virtual machine approach.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Oliver Betz - Oct 27 2:54:00 2005
Mike McCarty <Mike.McCarty@Mike...> wrote:
[inefficient code from GCC]
> > Inefficient library functions, or poor optimizing at all?
>
> Umm, have you ever done a GCC port? I did one for the Z8000,
no, that's beyond my capability.
> and the presumptions GCC places on the underlying processor
> are not satisfied by the 6811. So one ends up implementing
Very interesting, thanks for the clarification!
So I guess this applies also to the other GCC ports for small
processors?
[...]
> >>I've taken a stab at LCC, and it's also just a little bit "big"
> >>for the '11, but would be willing to reconsider LCC if anyone
> >
> > Indeed? AFAIK ICC is based on LCC.
>
> Yes, I've exchanged e-mail a few times with the author. He also
> used a virtual machine approach.
One could use ARM7 to avoid problems with "too big" compilers.
But I love the BDM debugging possibilities of the HC12, especially
watching (and setting) variables without any influence on the target
program. Gladly I don't depend on free tools (at least at work).
Oliver
--
Oliver Betz, Muenchen
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
[inefficient code from GCC]
> > Inefficient library functions, or poor optimizing at all?
>
> Umm, have you ever done a GCC port? I did one for the Z8000,
no, that's beyond my capability.
> and the presumptions GCC places on the underlying processor
> are not satisfied by the 6811. So one ends up implementing
Very interesting, thanks for the clarification!
So I guess this applies also to the other GCC ports for small
processors?
[...]
> >>I've taken a stab at LCC, and it's also just a little bit "big"
> >>for the '11, but would be willing to reconsider LCC if anyone
> >
> > Indeed? AFAIK ICC is based on LCC.
>
> Yes, I've exchanged e-mail a few times with the author. He also
> used a virtual machine approach.
One could use ARM7 to avoid problems with "too big" compilers.
But I love the BDM debugging possibilities of the HC12, especially
watching (and setting) variables without any influence on the target
program. Gladly I don't depend on free tools (at least at work).
Oliver
--
Oliver Betz, Muenchen
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Mike McCarty - Oct 27 3:03:00 2005
Oliver Betz wrote:
> Mike McCarty <Mike.McCarty@Mike...> wrote:
>
> [inefficient code from GCC]
[snip]
> Very interesting, thanks for the clarification!
Welcome.
> So I guess this applies also to the other GCC ports for small
> processors?
Yes.
> [...] >>>>I've taken a stab at LCC, and it's also just a little bit "big"
>>>>for the '11, but would be willing to reconsider LCC if anyone
>>>
>>>Indeed? AFAIK ICC is based on LCC.
>>
>>Yes, I've exchanged e-mail a few times with the author. He also
>>used a virtual machine approach. > One could use ARM7 to avoid problems with "too big" compilers.
I'm not familiar with the ARM processors. The point here is,
I have on hand more than 100 MC68HC11 processors just dieing to
be put into projects, and which I regularly program. I'd like
to have a relatively decent compiler. I did a port to the '11
of Small C which is now generating pretty tight code, and which
uses the '11 NATIVELY, IOW, with natural register usage, not
some sort of virtual machine. But I'm missing some parts of a
real C compiler.
I can either add structures and unions to Small C, and maybe
floating point (I did a floating point package, since the
freely available one on the net is truly inadequate), and
perhaps long integers. Really, structures I miss the most.
Long ints and floats are much less necessary.
> But I love the BDM debugging possibilities of the HC12, especially
> watching (and setting) variables without any influence on the target
> program. Gladly I don't depend on free tools (at least at work).
I've never used the '12.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
> Mike McCarty <Mike.McCarty@Mike...> wrote:
>
> [inefficient code from GCC]
[snip]
> Very interesting, thanks for the clarification!
Welcome.
> So I guess this applies also to the other GCC ports for small
> processors?
Yes.
> [...] >>>>I've taken a stab at LCC, and it's also just a little bit "big"
>>>>for the '11, but would be willing to reconsider LCC if anyone
>>>
>>>Indeed? AFAIK ICC is based on LCC.
>>
>>Yes, I've exchanged e-mail a few times with the author. He also
>>used a virtual machine approach. > One could use ARM7 to avoid problems with "too big" compilers.
I'm not familiar with the ARM processors. The point here is,
I have on hand more than 100 MC68HC11 processors just dieing to
be put into projects, and which I regularly program. I'd like
to have a relatively decent compiler. I did a port to the '11
of Small C which is now generating pretty tight code, and which
uses the '11 NATIVELY, IOW, with natural register usage, not
some sort of virtual machine. But I'm missing some parts of a
real C compiler.
I can either add structures and unions to Small C, and maybe
floating point (I did a floating point package, since the
freely available one on the net is truly inadequate), and
perhaps long integers. Really, structures I miss the most.
Long ints and floats are much less necessary.
> But I love the BDM debugging possibilities of the HC12, especially
> watching (and setting) variables without any influence on the target
> program. Gladly I don't depend on free tools (at least at work).
I've never used the '12.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
Re: Compiler Port Collaboration - Jaap van Ganswijk - Oct 27 23:42:00 2005
At 2005-10-27 09:03, Mike McCarty wrote:
>> One could use ARM7 to avoid problems with "too big" compilers.
>
>I'm not familiar with the ARM processors. The point here is,
>I have on hand more than 100 MC68HC11 processors just dieing to
>be put into projects, and which I regularly program. I'd like
>to have a relatively decent compiler. I did a port to the '11
>of Small C which is now generating pretty tight code, and which
>uses the '11 NATIVELY, IOW, with natural register usage, not
>some sort of virtual machine. But I'm missing some parts of a
>real C compiler.
>
>I can either add structures and unions to Small C, and maybe
>floating point (I did a floating point package, since the
>freely available one on the net is truly inadequate), and
>perhaps long integers. Really, structures I miss the most.
>Long ints and floats are much less necessary.
I wrote my own 6811 compiler, assembler and linker which are
way better than the Small C compiler that I learned a lot from
(especially how not to do it) and also a certain open source
68000 compiler which was full of errors (but was much more
sophisticated).
I used my own 6811-compiler to compile code for my work and
I was very pleased with it (but could of course adjust the
compiler at every problem that I encountered).
I also emailed with the 6811 GCC guy years ago. The 6811-version
of the GCC assumes a kind of virtual 32-bits processor with
multiple registers implemented in the direct page. Not a concept
to generate very compact code with.
I'm willing to turn my software into an open source
project and am even prepared to spend quite a lot of
(coordination) time on it, but it will require a lot
of work (of other volunteers).
The software consists of a family of assemblers for various
processors (from memory: Z80, 8086, 68000, Z8000, 6811,
6803, 6809, AM29000, PowerPC and many more), a very
universal linker and a dumper/downloader. There are
also set-ups for c-compilers for several processors,
but only the latest version of the 6811-compiler really
works quite well. I also have disassemblers for even
more processors, but that could be a separate project.
There is also a command line monitor program in C that
I managed to get compiled for several processors at some
time (Super8, 6803, 6811 for example) and which also
ran on a DOS-PC for example.
The disassemblers, assemblers and compilers consist of a lot
of shared files and per processor a limited number of dedicated
files.
It's also quite easy to add support for new processors. To
get to know a new processor I used to write a disassembler
in a couple of days. There is also a version for an 'ideal'
register-less stack processor for the compiler and assembler.
But instead of helping to set up this potentially massive
project you might want to consider that paying say $100 for
an existing well-supported compiler might be much cheaper
when you consider that time is money!
Greetings,
Jaap
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )
>> One could use ARM7 to avoid problems with "too big" compilers.
>
>I'm not familiar with the ARM processors. The point here is,
>I have on hand more than 100 MC68HC11 processors just dieing to
>be put into projects, and which I regularly program. I'd like
>to have a relatively decent compiler. I did a port to the '11
>of Small C which is now generating pretty tight code, and which
>uses the '11 NATIVELY, IOW, with natural register usage, not
>some sort of virtual machine. But I'm missing some parts of a
>real C compiler.
>
>I can either add structures and unions to Small C, and maybe
>floating point (I did a floating point package, since the
>freely available one on the net is truly inadequate), and
>perhaps long integers. Really, structures I miss the most.
>Long ints and floats are much less necessary.
I wrote my own 6811 compiler, assembler and linker which are
way better than the Small C compiler that I learned a lot from
(especially how not to do it) and also a certain open source
68000 compiler which was full of errors (but was much more
sophisticated).
I used my own 6811-compiler to compile code for my work and
I was very pleased with it (but could of course adjust the
compiler at every problem that I encountered).
I also emailed with the 6811 GCC guy years ago. The 6811-version
of the GCC assumes a kind of virtual 32-bits processor with
multiple registers implemented in the direct page. Not a concept
to generate very compact code with.
I'm willing to turn my software into an open source
project and am even prepared to spend quite a lot of
(coordination) time on it, but it will require a lot
of work (of other volunteers).
The software consists of a family of assemblers for various
processors (from memory: Z80, 8086, 68000, Z8000, 6811,
6803, 6809, AM29000, PowerPC and many more), a very
universal linker and a dumper/downloader. There are
also set-ups for c-compilers for several processors,
but only the latest version of the 6811-compiler really
works quite well. I also have disassemblers for even
more processors, but that could be a separate project.
There is also a command line monitor program in C that
I managed to get compiled for several processors at some
time (Super8, 6803, 6811 for example) and which also
ran on a DOS-PC for example.
The disassemblers, assemblers and compilers consist of a lot
of shared files and per processor a limited number of dedicated
files.
It's also quite easy to add support for new processors. To
get to know a new processor I used to write a disassembler
in a couple of days. There is also a version for an 'ideal'
register-less stack processor for the compiler and assembler.
But instead of helping to set up this potentially massive
project you might want to consider that paying say $100 for
an existing well-supported compiler might be much cheaper
when you consider that time is money!
Greetings,
Jaap
(You need to be a member of hc11 -- send a blank email to hc11-subscribe@yahoogroups.com )