68000 compiler?

didi wrote:
> On Feb 23, 6:51 pm, David Brown
> <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%).

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.

In article <jfydnepdJJ_rcjzUnZ2dnUVZ8u6dnZ2d@lyse.net>, 
david.brown@hesbynett.removethisbit.no says...
> myforwik@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?
> 
> 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.

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

<myforwik@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.  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

On 2009-03-02, Mark Moulding <mark@markesystems.no.damn.spam.com> wrote:
><myforwik@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

On Sun, 01 Mar 2009 18:33:17 -0600, Grant Edwards <grante@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.

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

On 2009-03-02, Paul Keinanen <keinanen@sci.fi> wrote:
> On Sun, 01 Mar 2009 18:33:17 -0600, Grant Edwards <grante@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?

--