Intermetrics 68k toolchain, 90's vintage?

[chriva]

Hi, people!

I've been working on a reverse-engineering / reimplementation of missing pieces-project of an old firmware for a year or so that originally used a version of Intermetrics C toolchain for 68k (Two different versions even. They switched to a "newer" one 1995. Something that is evident in logs and "vcs" files but no exact version numbers can be found in them or any of the makefiles).

The whole port is using gcc now but some of the last missing functions are way too big and complex for me to understand (we're talking several thousands of lines of disassembled code) so I'm basically forced to do it the stupid way, trial and error-style, by comparing the compiled output. Something that has worked before on smaller functions even if their ABI behaviour is not identical to gcc but these are just a little too extra... I eventually figured my only chance would be to use the original compiler and aim for an absolute carbon copy of my output vs the binary file.

This lead to several polite emails over the course of four-five months to Tasking Inc. (the current owner/iteration of intermetrics) which could not even be bothered to answer me (I don't really blame them. I doubt they even have any of the ancient versions stored anywhere) and eventually, present day, -where I pester you about it



Do you know where to find a "90's vintage" version of it or perhaps even have a copy you're willing to share?

Thank you in advance.
Sincerely.
Chris

Mod: I did ask Dave for permission before posting. (I'm really thankful for the permission and your time, sir.)

[0db]

Do you know where to find a "90's vintage" version of it or perhaps even have a copy you're willing to share?

Up to now, I have only seen demo versions with limitations 

[chriva]

Depending on how it's limited it might not be a problem.

I have no intention of compiling the whole project with it, only select functions and files so that I can compare the output against a stock binary

I have looked for demo versions too but only the latest and greatest could be found (and, surprise, they want you to email them to get a copy since it's remote activated).

Wild guess is that it should be fine if the limit is no less than 16-64K of binary data and maybe 30-40 symbols. And, ofc, of 90's vintage

[Doctorandus_P]

You have just confirmed my motto that if a uC does not run GCC, I won't touch it.

Even so,
Wish you lots of success with your project.

Did the old Atari 1024ST have an 68K, or some of the Commodores?
Would a compiler for one of those help you? 
Gust guessing...

[chriva]

I've tried maaaaany compilers and some are closer than others but none is identical:

gcc 2.95 (quite close but not near enough), several versions of gcc3.x, gcc4, microtec C of 1995 vintage~ (also quite close but still not near enough), several versions of metrowerks toolchains on mac and windows, an ancient Sierra compiler from the 80's, various diy projects etc etc

Haven't tried Amiga or Atari ones yet but I'll give em a try this weekend if I don't find enough time during the week.


Thank you

[brucehoult]

Uhh .. if the problem is just that the gcc ABI is different then it's probably not a big deal to hack gcc (or LLVM) to use the ancient ABI. Assuming you have a spec for it.

edit: I suspect Lauterbach could tell you what the ABI is.

[chriva]

I've been thinking about that too but I sadly don't have the required skills to pull it off. -At least not with my current knowledge.

Might be a fun project to learn from.



Few things I've noticed:
1. Logic is WASTLY different
2. gcc use moveq instead of clr.l
3. stack operations are done in opposite order when fetching data. (and they're using different registers)
4. Intermetrics C has a weird tendency to use d6/d7 for extra storage instead of gcc's ascending order scheme. d0/d1 first, then push and use registers in numbered order.
5. Intermetrics panics once the functions are large enough and start using any register free-for-all style instead of pushing and popping like gcc. be it address registers for data or data registers as temporary storage for an address.
6. Maths. DIVISON in particular is very, very different. intermetrics has a tendency to split up operations while gcc would rather work on huge numbers. both are using bitshifts and subtraction / addition to get the correct result but they do it differently. Some things you can work around by writing code menace style even tho I'm certain no one would ever write it that way.
7. gcc is very premature with everything and will load up registers much earlier than necessary (probably to make it more readable. Flags can slightly alleviate this but it's still quite severe).

They both adhere to one ABI rule tho: a0/a1 and d0/d1 are used as scratch registers

[chriva]

Update: Still no luck finding one so I did start dipping my toes in modifying gcc.

I was prepared for proper hell but it seems almost everything related to code generation can be found in ./gcc/gcc/config/m68k
(Well it's still hell but at least I don't have to search all over the folder hierarchy)

Most of the register allocation order-junk can be found in m68k.h so that didn't take long to modify.
Intermetrics does it back to front, d1,d0 are allocated as scratch registers (in that order). Then it goes d7,d6,d5,d4.. (these are backed up on the stack).
Address registers are even wilder: a4,a0 are scratch registers (in that order). Then a1,a2,a3,a5.
a6 is only used as frame pointer (and it's only used in 9 functions). I've just used #pragma push to enable that behaviour when need be.


Currently trying to figure out how to modify division and multiplication but I can't even find the code responsible for it... Ideas?

[chriva]

Slight update.

Still only tackling basics in gcc but I've managed to patch it enough to almost have the same register priority and slightly closer behaviour when it comes to division.
Let's say division by 1000 where gcc, before, would just go full toilet diver and convert it to (n x 274877907) / 64 and chop off the result instead of just emitting divu.