Sign in

Not a member? | Forgot your Password?

Search 68hc12

Search tips

Subscribe to 68hc12

Free PDF Downloads

Advanced Linux Programming

What Every Programmer Should Know About Memory

Introduction to Embedded Systems

C++ Tutorial

Embedded Systems - Theory and Design Methodology

Microcontroller Programming and Interfacing

Introduction to Microcontrollers


More Free PDF Downloads

Discussion Groups

See Also

ElectronicsDSPFPGA

Discussion Groups | 68HC12 | 68hc12 C compiler and assembly instruction set

Join our technical discussions about Freescale Microcontrollers: M68HC12. For more discussions, visit Freescale's official forums at community.freescale.com

68hc12 C compiler and assembly instruction set - Naheed M K - Aug 7 11:10:00 2003

Hi
Does anyone know where can I get any free C Compiler for 68hc12.
Also I would like to get a url for understanding complete instruction
set in detail for 68hc12.

Thanks
Naheed





Re: 68hc12 C compiler and assembly instruction set - Naheed M K - Aug 7 14:07:00 2003

Yup, I found it 12k size of code can be compiled by free standard
edition of codewarrior, Yaaahoooo. Thanks to google search.

http://www.metrowerks.com/MW/download/updates.asp?
date_op=on+or+after&year&month&day=1&did=find&vers=CWHC12&submit
=Select+Update+%3E%3E

Thanks
Naheed

--- In , "Naheed M K" <naheedmk@y...> wrote:
> Hi
> Does anyone know where can I get any free C Compiler for 68hc12.
> Also I would like to get a url for understanding complete
instruction
> set in detail for 68hc12.
>
> Thanks
> Naheed






Re: 68hc12 C compiler and assembly instruction set - Naheed M K - Aug 7 14:08:00 2003

Yup, I found it 12k size of code can be compiled by free standard
edition of codewarrior, Yaaahoooo. Thanks to google search.

http://www.metrowerks.com/MW/download/updates.asp?
date_op=on+or+after&year&month&day=1&did=find&vers=CWHC12&submit
=Select+Update+%3E%3E

Thanks
Naheed

--- In , "Naheed M K" <naheedmk@y...> wrote:
> Hi
> Does anyone know where can I get any free C Compiler for 68hc12.
> Also I would like to get a url for understanding complete
instruction
> set in detail for 68hc12.
>
> Thanks
> Naheed







Re: 68hc12 C compiler and assembly instruction set - waltel506v - Aug 7 14:35:00 2003

Your Yaaahoooo maybe short lived, once you start to decipher the
codewarrior help and documentation. Metrowerks will provide you no
help for this version.

Walt

--- In , "Naheed M K" <naheedmk@y...> wrote:
> Yup, I found it 12k size of code can be compiled by free standard
> edition of codewarrior, Yaaahoooo. Thanks to google search.
>
> http://www.metrowerks.com/MW/download/updates.asp?
> date_op=on+or+after&year&month&day=1&did=find&vers=CWHC12&submit
> =Select+Update+%3E%3E
>
> Thanks
> Naheed
>




Re: 68hc12 C compiler and assembly instruction set - Daniel Postler - Aug 8 1:33:00 2003

Am Thu, 07 Aug 2003 16:10:17 -0000 hat Naheed M K <>
geschrieben:

> Hi
> Does anyone know where can I get any free C Compiler for 68hc12. Also I
> would like to get a url for understanding complete instruction set in
> detail for 68hc12.
>
> Thanks
> Naheed

Try the GNU-tools at http://m68hc11.serveftp.org. It compiles also for
HC(S)12

For instruction set details you may look at the motorola website for the
HC(S)12-core manual. Sorry have no link.

Bye

Daniel Postler



_____________________________
 Free pdf download: Advanced Linux Programming.


Re: 68hc12 C compiler and assembly instruction set - Mysterious Mister Z - Aug 8 9:22:00 2003


The rest of the GNU stuff is:
http://savannah.gnu.org/projects/m68hc11
http://www.gnu.org/software/m68hc11/
(It says 68hc11, but it's also 68gc12 and mc9s12/68hcs12)
Installs easily in MS windows or linux.
There is a busy Yahoo newsgroup for support.

The code quality is as good as any commercial compiler, IMO.

Unlike free commercial "limited releases", there are no limits on
program size. --- In , "Naheed M K" <naheedmk@y...> wrote:
> Hi
> Does anyone know where can I get any free C Compiler for 68hc12.
> Also I would like to get a url for understanding complete instruction
> set in detail for 68hc12.
>
> Thanks
> Naheed







Re: 68hc12 C compiler and assembly instruction set - Oliver Betz - Aug 8 10:05:00 2003

Mysterious Mister Z wrote:

[GNU C for the HC12]

> The code quality is as good as any commercial compiler, IMO.

Which of them do you know (Cosmic, Metrowerks, ICC...)?

I assume you have some experience with GCC/HC12. I also had to decide
which compiler to use but I found that some library functions were
pretty bad. Nevertheless I'm interested how GNU C for the HC12 is
improved.

Could you please tell me how long (CPU cycles) an (unsigned
long)/(unsigned long) division and a (float)/(float) division takes
in the recent version?

If there is still no reasonable int math, I'm afraid that float
division is faster than long (thanks to Tim Housel).

Does the compiler use the 32 bit HC12 operations where possible, e.g.

U16 X, Y, Z;
X = (U16)(((U32)Y * 1000) / (U16)Z);

should use only emul and ediv, no library call.

After all, I really dislike the usage of soft registers (because I
use many interrupts). IMHO, for the HC12 it's not really necessary.

Oliver
--
Oliver Betz, Muenchen





Re: 68hc12 C compiler and assembly instruction set - Author Unknown - Aug 8 10:30:00 2003

In a message dated 8/8/03 11:06:58 AM Eastern Daylight Time,
writes:
Does the compiler use the 32 bit HC12 operations where possible, e.g.

U16 X, Y, Z;
X = (U16)(((U32)Y * 1000) / (U16)Z);

should use only emul and ediv, no library call.
=================================
This is a result I'd like to see for each compiler.





Re: 68hc12 C compiler and assembly instruction set - Daniel Friederich - Aug 8 11:07:00 2003

Hi Oliver,

the problem for an ANSI C compiler with performing

U16 X, Y, Z;
X = (U16)(((U32)Y * 1000) / (U16)Z);

with an EMUL and an EDIV is that if the 32/16 bit EDIV division overflows, then the
HC12 does not generate a result at all (it just sets the V flag). Therefore using a simple EDIV does not generate the same result
for all possible Y and Z's as calculating it with longs.

Our metrowerks compiler does generate the code you are expecting, but only if you are specifying the option -PEDiv. The default is
the save (and slower) long division.
Apart from this, we are also not using any "soft registers".

Bye

Daniel > -----Original Message-----
> From: Oliver Betz [mailto:]
> Sent: Friday, August 08, 2003 17:06
> To:
> Subject: Re: [68HC12] Re: 68hc12 C compiler and assembly instruction set > Mysterious Mister Z wrote:
>
> [GNU C for the HC12]
>
> > The code quality is as good as any commercial compiler, IMO.
>
> Which of them do you know (Cosmic, Metrowerks, ICC...)?
>
> I assume you have some experience with GCC/HC12. I also had to decide
> which compiler to use but I found that some library functions were
> pretty bad. Nevertheless I'm interested how GNU C for the HC12 is
> improved.
>
> Could you please tell me how long (CPU cycles) an (unsigned
> long)/(unsigned long) division and a (float)/(float) division takes
> in the recent version?
>
> If there is still no reasonable int math, I'm afraid that float
> division is faster than long (thanks to Tim Housel).
>
> Does the compiler use the 32 bit HC12 operations where possible, e.g.
>
> U16 X, Y, Z;
> X = (U16)(((U32)Y * 1000) / (U16)Z);
>
> should use only emul and ediv, no library call.
>
> After all, I really dislike the usage of soft registers (because I
> use many interrupts). IMHO, for the HC12 it's not really necessary.
>
> Oliver
> --
> Oliver Betz, Muenchen >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/






_____________________________
 Free pdf download: What Every Programmer Should Know About Memory.


Re: 68hc12 C compiler and assembly instruction set - Oliver Betz - Aug 8 11:19:00 2003

wrote:

> U16 X, Y, Z;
> X = (U16)(((U32)Y * 1000) / (U16)Z);
>
> should use only emul and ediv, no library call.
> =================================
> This is a result I'd like to see for each compiler.

well, Cosmic produces this (obviously without the comments):

ldd _Y
ldy #1000 ; works also with a variable
emul
ldx _Z ; works also with a constant value
ediv
sty _X

it's a piece of code I use pretty often for fast (fixed point)
scaling, and I was happy to see that Cosmic produces optimal code.

Oliver
--
Oliver Betz, Muenchen




Re: 68hc12 C compiler and assembly instruction set - Oliver Betz - Aug 9 8:08:00 2003

Daniel Friederich wrote:

> the problem for an ANSI C compiler with performing
>
> U16 X, Y, Z;
> X = (U16)(((U32)Y * 1000) / (U16)Z);
>
> with an EMUL and an EDIV is that if the 32/16 bit EDIV division overflows, then the
> HC12 does not generate a result at all (it just sets the V flag).
> Therefore using a simple EDIV does not generate the same result

Right, I forgot to mention this. Therefore one can tell the
"advanced" compiler that he is aware of this "problem" and wants to
have the fast but not 100% ANSI solution. After all, in _most_ cases
the result of an overflowed division is useless, no matter whether
it's the truncated correct result or something else.

As Bob Gardner wrote: it would be interesting how this is handled by
the other (ICC, GCC) compilers: is it possible to use the fast "ediv"
version, and how do I tell it the compiler? Can I set it on a "per
statement" basis (Cosmic typecast) or on a "per file" basis (Hiware -
pediv)?

BTW: a #pragma would be the cleanest solution, wouldn't it?

> Apart from this, we are also not using any "soft registers".

It would also be interesting to know whether e.g. ICC still needs
them.

Oliver
--
Oliver Betz, Muenchen




Re: 68hc12 C compiler and assembly instruction set - Mysterious Mister Z - Aug 11 10:01:00 2003

--- In , "Oliver Betz" <list_ob@g...> wrote:
> Mysterious Mister Z wrote:
>
> [GNU C for the HC12]
>
> > The code quality is as good as any commercial compiler, IMO.
>
> Which of them do you know (Cosmic, Metrowerks, ICC...)?
>
> I assume you have some experience with GCC/HC12. I also had to decide
> which compiler to use but I found that some library functions were
> pretty bad. Nevertheless I'm interested how GNU C for the HC12 is
> improved.
>
> Could you please tell me how long (CPU cycles) an (unsigned
> long)/(unsigned long) division and a (float)/(float) division takes
> in the recent version?
>
> If there is still no reasonable int math, I'm afraid that float
> division is faster than long (thanks to Tim Housel).
>
> Does the compiler use the 32 bit HC12 operations where possible, e.g.
>
> U16 X, Y, Z;
> X = (U16)(((U32)Y * 1000) / (U16)Z);
>
> should use only emul and ediv, no library call.
>
> After all, I really dislike the usage of soft registers (because I
> use many interrupts). IMHO, for the HC12 it's not really necessary.
>
> Oliver
> --
> Oliver Betz, Muenchen

Oliver, you are partly correct. The GNU compiler made a call to a
library function for the division, but not the multiplication. Whether
this is "bad" or not depends on whether or not you like your division
errors tracable.

Of course, one example means very little. It's quite possible to
compare any two compilers with a little selective nitpicking and
"prove" one is ... well, whatever you want. All this leads to is an
exchange of strawmen and a flame war, so I won't go there.

In my view, the making of compilers is no longer the rocket science it
used to be. They are all pretty good, and they all have
idiosyncracies. The only things really worth looking at are:

What is the total cost of ownership?
Will it help you reach deadlines better than another?
Is the support of a type, level and quality you need?
Is the value added by included extras (IDE, debug tools, help
functions and so on) right for YOU?
Are you comfortable with it's way of doing things?

Each of these is somewhat situational as well. If you are on a tight
budget, tool costs can be a very big deal (consider a price range that
varies from $0 to $5,000 or more - $5,000 buys a fair bit of learning
time, parts, protoype boards and so on). But familiarity might also
play a part. If you know and use toolset X and its features, it's
probably something you want to stay with.

Where I work, we have embedded tools for some 8 different processors,
and a near equal variety of tools. One engineer abandoned a "high end"
gui-based IDE in favor of a variety of command line tools and
standalone editors (he still uses the package's underlying compiler,
linker, etc). He and I both have problems with tools that too often do
more than you want, and have learning curves that are just as brutal
as "manual" methods. Yet there are others here who would never
consider anything but fat point-and-click wrappers around the
compiler/linker/debugger set. To each his own.

Code generation is rarely (never?) the issue. You can't evaluate it
anyway, except in your own projects and by actually using several
tools. A very expensive and time consuming proposition. Generalisms
don't apply because everybody is releasing new stuff and bugfixes all
the time - generalisms become dated very fast.

I still stand by my assertion that GNU is the way to go when you have
time but not money. But it is not the only consideration of course.

-z





Re: 68hc12 C compiler and assembly instruction set - Oliver Betz - Aug 12 8:37:00 2003

Mysterious Mister Z wrote:

> Oliver, you are partly correct. The GNU compiler made a call to a
> library function for the division, but not the multiplication. Whether
> this is "bad" or not depends on whether or not you like your division
> errors tracable.

and on the quality of the library routine for division - you didn't
say anything about this.

> Of course, one example means very little. It's quite possible to

there are more, but I didn't have the time to investigate this
further, it was cheaper to buy the Cosmic compiler.

> compare any two compilers with a little selective nitpicking and
> "prove" one is ... well, whatever you want. All this leads to is an
> exchange of strawmen and a flame war, so I won't go there.

No - it shows that making a _good_ port is much work. Stephane Carrez
did a good job, but he simply doesn't have the time to provide a high
degree of optimization. And there are not as many contributors as
compared to other GCC ports.

> In my view, the making of compilers is no longer the rocket science it
> used to be. They are all pretty good, and they all have

No, but it's a _lot_ of work.

> idiosyncracies. The only things really worth looking at are:
>
> What is the total cost of ownership?
> Will it help you reach deadlines better than another?
> Is the support of a type, level and quality you need?
> Is the value added by included extras (IDE, debug tools, help
> functions and so on) right for YOU?
> Are you comfortable with it's way of doing things?

So if you have to count your work time, the paid HC12 compilers are
still cheaper.

[...]

> Where I work, we have embedded tools for some 8 different processors,
> and a near equal variety of tools. One engineer abandoned a "high end"
> gui-based IDE in favor of a variety of command line tools and
> standalone editors (he still uses the package's underlying compiler,

I use the Cosmic compiler with make, makedepend and my favourrite
editor. Setting the compiler options and making a link file are the
only specific tasks.

[...]

> Code generation is rarely (never?) the issue. You can't evaluate it

Code generation is the main issue if it's bad. If a long/long
division takes 2000 cycles instead of 200, you could be in a
situation where it's simply not possible to do the job. Or if your
interrupt routine has to save several bytes to local storage
therefore being slower and/or not re-entrant.

[...]

> I still stand by my assertion that GNU is the way to go when you have
> time but not money. But it is not the only consideration of course.

Ack. But I didn't see this statement in your original post. You only
wrote "The code quality is as good as any commercial compiler, IMO."
And that's not true. The commercial compilers generate nearly optimal
code (at least the two expensive ones). Rarely you can make it much
better by using assembler.

Oliver
--
Oliver Betz, Muenchen





Re: 68hc12 C compiler and assembly instruction set - Mysterious Mister Z - Aug 12 10:27:00 2003


Oliver,

These kinds of discussions rapidly devolve into "I'm right, You're
wrong" threads, with an ongoing exchange minutae, strawmen,
situational comments, generalizations, and True Beliefs. The flamer
with the most free time and general verbosity usually "wins".

The thing is, if Cosmic works for you, what I have to say about GNU or
any competing commercial compiler is irrelevant. I have no interest in
selling you on GNU or anything else.

I can only make suggestions based on the info available, and in this
case it started with someone asking for a free toolset. We seem to
have diverged from that rather rapidly. I made arguable claims (and
all relative claims are arguable), but so what? You make the claim
that buying is cheaper. I didn't see you make a case for that, other
than it took a long time to evaluate a compiler. But that's not a case
as you could have just acquired and used it, same as any other (see
how easy and pointless this is?).

In one of the commercial compilers, I note a significant avoidance of
the Y register. It's a respected compiler, but I can easily see how
using Y would make for some serious code shrinkage (I'm one of those
people who usually checks the compiler's assembly output). But this
means nothing- another compiler might use Y, but do something else
less than optimal. It doesn't matter on another level: it makes code
that is certainly good enough for me.

In my "ideal" limited-budget situation, I'd rather spend money on a
big honking hardware emulator than any compiler. When you hit certain
classes of problems, these things will save your more time than your
accumulated vacation. And certainly more than the learning curve
difference between any two toolsets several times over.

-z

--- In , "Oliver Betz" <list_ob@g...> wrote:
> Mysterious Mister Z wrote:
>
> > Oliver, you are partly correct. The GNU compiler made a call to a
> > library function for the division, but not the multiplication. Whether
> > this is "bad" or not depends on whether or not you like your division
> > errors tracable.
>
> and on the quality of the library routine for division - you didn't
> say anything about this.
>
> > Of course, one example means very little. It's quite possible to
>
> there are more, but I didn't have the time to investigate this
> further, it was cheaper to buy the Cosmic compiler.
>
> > compare any two compilers with a little selective nitpicking and
> > "prove" one is ... well, whatever you want. All this leads to is an
> > exchange of strawmen and a flame war, so I won't go there.
>
> No - it shows that making a _good_ port is much work. Stephane Carrez
> did a good job, but he simply doesn't have the time to provide a high
> degree of optimization. And there are not as many contributors as
> compared to other GCC ports.
>
> > In my view, the making of compilers is no longer the rocket science it
> > used to be. They are all pretty good, and they all have
>
> No, but it's a _lot_ of work.
>
> > idiosyncracies. The only things really worth looking at are:
> >
> > What is the total cost of ownership?
> > Will it help you reach deadlines better than another?
> > Is the support of a type, level and quality you need?
> > Is the value added by included extras (IDE, debug tools, help
> > functions and so on) right for YOU?
> > Are you comfortable with it's way of doing things?
>
> So if you have to count your work time, the paid HC12 compilers are
> still cheaper.
>
> [...]
>
> > Where I work, we have embedded tools for some 8 different processors,
> > and a near equal variety of tools. One engineer abandoned a "high end"
> > gui-based IDE in favor of a variety of command line tools and
> > standalone editors (he still uses the package's underlying compiler,
>
> I use the Cosmic compiler with make, makedepend and my favourrite
> editor. Setting the compiler options and making a link file are the
> only specific tasks.
>
> [...]
>
> > Code generation is rarely (never?) the issue. You can't evaluate it
>
> Code generation is the main issue if it's bad. If a long/long
> division takes 2000 cycles instead of 200, you could be in a
> situation where it's simply not possible to do the job. Or if your
> interrupt routine has to save several bytes to local storage
> therefore being slower and/or not re-entrant.
>
> [...]
>
> > I still stand by my assertion that GNU is the way to go when you have
> > time but not money. But it is not the only consideration of course.
>
> Ack. But I didn't see this statement in your original post. You only
> wrote "The code quality is as good as any commercial compiler, IMO."
> And that's not true. The commercial compilers generate nearly optimal
> code (at least the two expensive ones). Rarely you can make it much
> better by using assembler.
>
> Oliver
> --
> Oliver Betz, Muenchen