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).
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.
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.
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.
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).
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.
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.
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).
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.
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.
That I understand. What I don't understand is why the OP should use "an old version of gcc".
But, when switching from one compiler "vendor" to another, why not use the latest version of the compiler to which you're switching?