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
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.
David Brown schrieb:
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
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.
You could try the AS macroassembler:
Maybe this is easier than GCC, because I think the syntax of the GCC assembler is very unusual, compared to other assemblers.
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
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.
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
. , .
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
------------------------------------------------------
Original message:
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.
Keith & Dave Walker did/do maintain a c compiler for the 68000 processor (c68) and also for the 8086x (c386). Try searching the web for their names & compiler names.
Hul
snipped-for-privacy@gmail.com wrote:
l
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
------------------------------------------------------
Original message:
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.
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
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
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
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
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?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.