68000 compiler?
myfo...@gmail.com
modify, it was written for use with the SDS cross compiler, however I
can't find anyone that sells it anymore.
What would you recommend to use as a 68000 compile (target chip is
actually 68332)
Is there a good free 68000 compiler? Just use an old version of gcc?
David Brown
Use a current version of gcc, not an old one. 68k compilers are
generally labelled as "ColdFire" these days, but I don't think there are
any which will not generate code targeted for the 68332 (a.k.a. CPU32).
Try www.codesourcery.com, and take your pick from totally free versions
or paid-for versions with support, Eclipse integration, etc.
Of course, any SDS-specific code or libraries will need to be modified,
but that's the case whenever you change compilers in embedded development.
Frank-Christian Krügel
>> What would you recommend to use as a 68000 compile (target chip is
>> actually 68332)
>> Is there a good free 68000 compiler? Just use an old version of gcc?
>
> Use a current version of gcc, not an old one. 68k compilers are
> generally labelled as "ColdFire" these days, but I don't think there are
> any which will not generate code targeted for the 68332 (a.k.a. CPU32).
Coldfire is a RISCified 68k successor - same register set, less
addressing modes, less complex operations, plus some additional opcodes.
It's NOT 100% compatible.
gcc uses the same backend für 68k and coldfire, but you can disable
either support during gcc build, so not all versions have to support both.
--
Mit freundlichen Grüßen
Dipl.-Ing. Frank-Christian Krügel
David Brown
> David Brown schrieb:
>
>>> What would you recommend to use as a 68000 compile (target chip is
>>> actually 68332)
>>> Is there a good free 68000 compiler? Just use an old version of gcc?
>>
>> Use a current version of gcc, not an old one. 68k compilers are
>> generally labelled as "ColdFire" these days, but I don't think there
>> are any which will not generate code targeted for the 68332 (a.k.a.
>> CPU32).
>
> Coldfire is a RISCified 68k successor - same register set, less
> addressing modes, less complex operations, plus some additional opcodes.
> It's NOT 100% compatible.
>
None of the 68k family are 100% compatible - The 68060 has many opcodes
that did not exist in the 68000, and the 68000 has addressing modes that
are missing from the 68060. The same applies to the ColdFire. Still,
the ISA is the same - the ColdFire is a re-implementation of the same ISA.
> gcc uses the same backend für 68k and coldfire, but you can disable
> either support during gcc build, so not all versions have to support both.
>
I didn't know it was possible to disable support for particular devices
during gcc ./configure, but if so, I think it is extremely unlikely that
you will find downloadable binaries that have the CPU32 disabled. It
would only really be useful for people building from source who want to
make an absolute minimal system that supports their devices (for
example, to save time building all the extra libraries). So I stand by
my assertion (until proved wrong in practice, not just in theory) - find
a "ColdFire" compiler and it will support the 68332. It will also
generate slightly better code if you specify the 68332 (or CPU32) rather
than the 68000.
Frank Buss
You could try the AS macroassembler:
http://john.ccac.rwth-aachen.de:8000/as/
Maybe this is easier than GCC, because I think the syntax of the GCC
assembler is very unusual, compared to other assemblers.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss
> Maybe this is easier than GCC, because I think the syntax of the GCC
> assembler is very unusual, compared to other assemblers.
Of course: If the SDS cross compiler was a C compiler, GCC would be fine.
There are many switches to enable and disable opcodes for different 68000
types.
didi
wrote:
> ...
> > Coldfire is a RISCified 68k successor - same register set, less
> > addressing modes, less complex operations, plus some additional opcodes.
> > It's NOT 100% compatible.
>
> None of the 68k family are 100% compatible - The 68060 has many opcodes
> that did not exist in the 68000, and the 68000 has addressing modes that
> are missing from the 68060. The same applies to the ColdFire. Still,
> the ISA is the same - the ColdFire is a re-implementation of the same ISA.
That's more or less true, but the 020+ (up to the 060, I believe - but
I
never touched one of these, I used the CPU32 and the 020) has all of
the addressing modes of the 68000 plus many new ones. That is, user
level
code for the 68000 would just run on a 020 or a CPU32 (without causing
illegal opcode exceptions, that is).
Coldfire is close to all of these but is clearly not 100% compatible
to neither of them. Pretty similar, though - unless you have some code
written for the 020 or CPU32 which uses the addressing modes not
available
on the CF, this can be quite a pain.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/ac56758e8a0e8cad?dmode=source
David Brown
> On Feb 23, 12:28 pm, David Brown
> <da...@westcontrol.removethisbit.com> wrote:
>> ...
>>> Coldfire is a RISCified 68k successor - same register set, less
>>> addressing modes, less complex operations, plus some additional
>>> opcodes. It's NOT 100% compatible.
>> None of the 68k family are 100% compatible - The 68060 has many
>> opcodes that did not exist in the 68000, and the 68000 has
>> addressing modes that are missing from the 68060. The same applies
>> to the ColdFire. Still, the ISA is the same - the ColdFire is a
>> re-implementation of the same ISA.
>
> That's more or less true, but the 020+ (up to the 060, I believe -
> but I never touched one of these, I used the CPU32 and the 020) has
> all of the addressing modes of the 68000 plus many new ones. That is,
> user level code for the 68000 would just run on a 020 or a CPU32
> (without causing illegal opcode exceptions, that is). Coldfire is
> close to all of these but is clearly not 100% compatible to neither
> of them. Pretty similar, though - unless you have some code written
> for the 020 or CPU32 which uses the addressing modes not available on
> the CF, this can be quite a pain.
>
I can't find any references to op-codes or addressing modes that were
dropped from the 68040 or 68060 - it's always possible that I'm
imagining things. It is certainly the case that the 68040 and 68060
runs faster doing complex addressing by hand (i.e., using multiple adds,
shifts and moves) rather than by using the complex addressing modes
directly - but it looks like they are still available if you want. I'll
confirm this when (if) I can find my 68k reference book.
d...@kbrx.com
(c68) and also for the 8086x (c386). Try searching the web for their names
& compiler names.
Hul
didi
<david.br...@hesbynett.removethisbit.no> wrote:
> ....
> > That's more or less true, but the 020+ (up to the 060, I believe -
> > but I never touched one of these, I used the CPU32 and the 020) has
> > all of the addressing modes of the 68000 plus many new ones. That is,
> > user level code for the 68000 would just run on a 020 or a CPU32
> > (without causing illegal opcode exceptions, that is). Coldfire is
> > close to all of these but is clearly not 100% compatible to neither
> > of them. Pretty similar, though - unless you have some code written
> > for the 020 or CPU32 which uses the addressing modes not available on
> > the CF, this can be quite a pain.
>
> I can't find any references to op-codes or addressing modes that were
> dropped from the 68040 or 68060 - it's always possible that I'm
> imagining things. It is certainly the case that the 68040 and 68060
> runs faster doing complex addressing by hand (i.e., using multiple adds,
> shifts and moves) rather than by using the complex addressing modes
> directly - but it looks like they are still available if you want. I'll
> confirm this when (if) I can find my 68k reference book.
That would be an unnecessary effort. Last time I wrote a 68K (CPU32)
assembler was > 10 years ago... and I hate to think how many years
before that I wrote the former one. IIRC there were no user mode
opcodes & addressing modes dropped on the way up, although I have
some vague impression there was some minor exception to that for the
060
(but my level of confidence to that is within 10%).
I'll be using some of the new tiny Coldfire parts before too long
so my 68k assembler will come into play again, but I may get away with
just adding a few macros and not having to make a new version of it
at all (this is how I made it - back in the day - assemble 68hc11
code,
just a macro file included was all it took).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/638858e10adc657a?dmode=source
David Brown
That confirms what I've now seen in "Assembly Language and Systems
Programming for the M68000 family" (which I last looked at over 10 years
ago). Advanced addressing modes have been dropped from compilers and
code generators when compiling for the 68040 or 68060, but they have not
been dropped from the devices themselves.
> I'll be using some of the new tiny Coldfire parts before too long
> so my 68k assembler will come into play again, but I may get away with
> just adding a few macros and not having to make a new version of it
> at all (this is how I made it - back in the day - assemble 68hc11
> code,
> just a macro file included was all it took).
>
There is definitely some variation between the different ColdFire cores,
especially when you are using the more specialised instructions (there's
lots of differences in the different MAC units, for example). But as
far as I remember, the main difference compared to the 68k is that
addressing modes are more limited - no instruction is longer than 3
16-bit words, and you can't have more than one indirect operand in an
instruction.
Gene S. Berkowitz
david...@hesbynett.removethisbit.no says...
Just an FYI, SDS was purchased by Wind River Systems years ago, along
with Diab.
WR still offers the Diab compiler, I suppose it's possible they could
still provide you with SDS...
--Gene
Mark Moulding
I have an old project using, in fact, the 68332. I used an ancient version
of GCC (gcc version 2.5.3, and gas version 2.1.1) provided (and supported
by) DJ Delorie. This was back in 1994 (incredibly). I've since carted
around the entire configured compiler tree (C:\HAC) and just installed
(copied) it whenever I needed to do a bit of maintenance.
This was probably not a useful anecdote in itself, but basically, yes, an
old version of GCC would work just fine. Naturally, as another poster
pointed out, the compiler (and assembler) options need to be set correctly
for the target chip, and the startup code and libraries need to be written
for your target system (if it's not running a known OS).
--
Mark Moulding
Grant Edwards
><myfo...@gmail.com> wrote:
>> I have some code for a 68000 based system that I need to
>> compile/ modify, it was written for use with the SDS cross
>> compiler, however I can't find anyone that sells it anymore.
>>
>> What would you recommend to use as a 68000 compile (target
>> chip is actually 68332) Is there a good free 68000 compiler?
>> Just use an old version of gcc?
>
> I have an old project using, in fact, the 68332. I used an
> ancient version of GCC (gcc version 2.5.3, and gas version
> 2.1.1) provided (and supported by) DJ Delorie. This was back
> in 1994 (incredibly). I've since carted around the entire
> configured compiler tree (C:\HAC) and just installed (copied)
> it whenever I needed to do a bit of maintenance.
>
> This was probably not a useful anecdote in itself, but
> basically, yes, an old version of GCC would work just fine.
I still don't understand why everybody keeps specifying "an old
version" of gcc. AFAICT, the current version supports the m68k
architecture -- why must one use an old version?
--
Grant
Paul Keinanen
wrote:
>I still don't understand why everybody keeps specifying "an old
>version" of gcc. AFAICT, the current version supports the m68k
>architecture -- why must one use an old version?
The old code might rely on some not so well defined features of the
old compiler and a suspectable construct might compile differently in
a new gcc version. The run time library might also have some version
dependencies.
When doing close to end of life maintenance to some code, the risk
that a fix or a small modification would cause problems somewhere else
is much smaller, when using the original compiler version.
For an actively maintained software, it makes sense to use the current
version of the tool chain, fix any ambiguities in the code and
possibly recertify the whole software.
Paul
Grant Edwards
> On Sun, 01 Mar 2009 18:33:17 -0600, Grant Edwards <gra...@visi.com>
> wrote:
>
>>I still don't understand why everybody keeps specifying "an old
>>version" of gcc. AFAICT, the current version supports the m68k
>>architecture -- why must one use an old version?
>
> The old code might rely on some not so well defined features of the
> old compiler and a suspectable construct might compile differently in
> a new gcc version. The run time library might also have some version
> dependencies.
According to the OP, the "old code" was written for the SDS
compiler. I don't see why one would assume that an old version
of gcc would be more compatible with the SDS compiler just
because it's the same age as the SDS compiler.
> When doing close to end of life maintenance to some code, the
> risk that a fix or a small modification would cause problems
> somewhere else is much smaller, when using the original
> compiler version.
That I understand. What I don't understand is why the OP
should use "an old version of gcc".
> For an actively maintained software, it makes sense to use the
> current version of the tool chain, fix any ambiguities in the
> code and possibly recertify the whole software.
But, when switching from one compiler "vendor" to another, why
not use the latest version of the compiler to which you're
switching?
--