Re: gcc-toolchain for freescale's MC9S12X (68HCS12) ??

On 2008-05-29, Florian E. Teply <onlinefloh@xxxxxxxxxxxxxxxx> wrote:

And -- i just checked -- the gcc man page lists in the "machine dependent
options" section the options -m68hc12 and -m68hcs12 in version 4.3.0.
I'll probably try and get this to work, but as said: using gcc as a mere
syntax checker would already be a start.

Gcc is a single-target design: you have to build a separate gcc
installation for each target architecture. IOW, you can't
switch from IA32 to HC12 target architecture by merely changing
the command line arguments passed to a single gcc binary.

It is quite possible to use gcc for a different target as a static
analysis tool. I've done that along with a commercial compiler for a
target (I've forgotten which - it was a long time ago) - gcc "compiles"
the program natively for the host (linking tended to fail...). It might
mean a little bit of fiddling to get the right headers at the right
place, and perhaps an extra header defining macros for any compiler
extensions used by the real target compiler, but it can often work well.
You can also use gcc to generate the makefile dependencies at the same
time.

An alternative is to use a dedicated static analysis tool. The big one
is PC-Lint, which is a reasonable price on Windows (but absurdly four
times the price on Linux - and I doubt they support PPC Linux). The
open source option is splint, which should be fine on your system.

Thanks, will have a look at splint.

In my experience splint is useless for real world work. It'll
warn you about code like this:

uint8_t b;
b = 1;

Splint is unhappy because b is 8 bits wide and "1" is 16 or 32
bits wide (depending on your target), and the assignment is
loosing bits. If you turn that warning off, then you _won't_
get warned about code like this:

uint32_t u;
uint8_t b;
b = 123456789L;
b = u;

The only solution is to completely cover your code with
type-casts. The result is code without splint warnings, but
it's completely impossible to read/maintain.

I looked into trying to fix up splint to make it useful for
real work, but gave up after looking at the internals. The
"owners" of splint acknowledged on the splint mailing list that
splint was intended for language research and not for use with
real programs.

--
Grant Edwards grante Yow! Is this going to
at involve RAW human ecstasy?
visi.com
.

Relevant Pages

  • Re: Splint 3.1.2 release 16 Jan 2008 (MS-DOS)
    ... I think Splint cannot parse 'far' type modifier. ... It should be noticed that Splint is a tool that is a little bit unix and gcc ... It is simply ANSI C and nothing else. ... My port is neither a port to MSDOS nor to WinXP or what ever else. ...
    (comp.os.msdos.djgpp)
  • Re: reference-counted dynamic tag-union objects
    ... I've changed that to dec for better symmetry ... Is it worthwhile to boast that it passes gcc -Wall ... and splint -weak? ...
    (comp.lang.c)
  • Re: Is lint adopted into gcc?
    ... > In Redhat 9.0 package, ... > Is all functionalities moved into gcc with -Wall? ... Look out for 'splint', which seems to be a rewrite of lint. ...
    (comp.programming)
  • Re: Whats the story with the "end of XP"?
    ... Support gives them access to the larger body ... The same compiler suite may be "best" in both ... In the case of ByteCraft compilers, you are truly expert in your field, you work closely and rapidly with customers if there are any issues, and you have top class testing and quality control. ... understanding the inner workings of a relatively simple compiler like GCC ...
    (comp.arch.embedded)
  • [RFC][PATCH-2.6] Clean up and merge compiler-*.h
    ... the kernel headers in include/linux to include/linux-abi. ... * Common definitions for all gcc versions go here. ... -/* Some compiler specific definitions are overwritten here ...
    (Linux-Kernel)