When you look at the code of a 35 year old game...

[Bruce Abbott]

Originally Posted by hooverphonique

Is it even possible to reliably identify that some binary was compiled from C? I mean, you can generally tell by the structure of the disassembly if it originally was compiled from a higher level language, or written directly in asm, but how would you identify it as originating from C?

There are some general features of C vs other languages that may be visible in the machine code, eg. how parameters are passed on the stack. But each compiler also produces code that produces a unique 'fingerprint' specific to that compiler. Blitz BASIC code looks very different to SASC code, which is quite different from gcc code etc.

[Karlos]

What Bruce said. A lot of compilers have intrinsics to support C language features that are quite easy to spot once you've seen them before.

[hooverphonique]

ok.. so the answer is "no" when using the qualifiers "generally" and "reliably", but f/a 18 is probably compiled using some well-known compiler :-)

[8bitbubsy]

Originally Posted by Karlos

I dunno, this decade you only have to identify as a nerd, and anyone contradicting you is a vicious bigot that must be cancelled.

More truthful words have never been spoken... It's a weird time we live in.

[Bruce Abbott]

Originally Posted by hooverphonique

ok.. so the answer is "no" when using the qualifiers "generally" and "reliably", but f/a 18 is probably compiled using some well-known compiler :-)

F/A 18 appears to be ~1/3rd C and 2/3rds assembler. The C code looks like Lattice, which would make sense since it was the official compiler for the Amiga. To prove it I would have to compile some code with an early version of Lattice C and see what it produced.

[A500]

This discussion is very intriguing, like watching a detective story of sorts

[ara]

I found a function in the binary that is only called when some bytes are set to 1. I don't see them being written anywhere in the code, so I guess it's a function meant for debugging.

The attached picture shows the result. The small diagonal line in the top left corner is drawn every odd frame. The three-digit number is the frame rate (but not in fps, the base seems to be 800000). The other two numbers are the x and y input of the input controller.

[Ray Norrish]

I recall when you look at code made in pure assembler in a decompiler, it looks "clean" in comparison for want of a better word. I seemed to remember encountering BCD more frequently in non-ASM compiled code.
Also, there's frequently obvious bloat in higher level compilers. I expect that the exec stub would have some kind of uniqueness, as well as what sort of mem alloc pieces there are.
I expect one of the number of ex-crackers on here would recognise code structure from their typical tracing experiences.

[ara]

The compilers in the 1980s were not as much optimizing as the modern ones. For example, I don't remember to have ever seen loop unrolling in old compiled code. In addition, in code written in assembly language you can find structures that don't appear in compiled code. Typical example: code shared between several functions, like this:

function1:
     some instructions
function:
     some instructions
     rts

That said, I have to say that the parts of the Interceptor game written in assembly (most of the game core) look rather ugly (sorry dear author) and I definitely have a much harder time to annotate it with meaningful symbols and type names than I had with Starglider 2 and Carrier Command.

Do you know which game was written almost entirely in C? Populous. The code is very easy to read. I started translating it to Java and actually finished the game initialization and rendering part (see the attached picture), but at some point implementing all the game logic became too boring (so many "if"s....)

[qz3fwd]

Doesn’t IDA Pro decompile nowadays? Last time I looked at it about 10+ years ago I thought it did?

[A500]

Originally Posted by ara

Do you know which game was written almost entirely in C? Populous.

Theoretically speaking, would this mean that the game could be further optimized at least to a modestly significant degree by hand-written assembler? I'm assuming here that the compiled C code from 1991 is not as efficient.

[ara]

Originally Posted by A500

Theoretically speaking, would this mean that the game could be further optimized at least to a modestly significant degree by hand-written assembler?

Here is a fragment of C code that I reverse-engineered with the help of Ghidra. It comes from a function that flattens a 9x9 patch of land for the AI player:

(player->action).id = 2;  // land lowering action
(player->action).x = x;
(player->action).y = y;
player->moveDone = 1;

Looks clean, right? Here are the actual machine instructions from the binary of the game:

movea.l   (-0xe,A5),A0
move.b    #0x2,(A0)
movea.l   (-0xe,A5),A0
move.b    d4,(0x1,A0)
movea.l   (-0xe,A5),A0
move.b    d5,(0x2,A0)
movea.l   (-0xe,A5),A0
move.w   #0x1,(0x8,A0)

There are some optimization opportunities

[Karlos]

Originally Posted by ara

Here is a fragment of C code that I reverse-engineered with the help of Ghidra. It comes from a function that flattens a 9x9 patch of land for the AI player:

(player->action).id = 2;  // land lowering action
(player->action).x = x;
(player->action).y = y;
player->moveDone= 1;

Looks clean, right? Here are the actual machine instructions from the binary of the game:

movea.l   (-0xe,A5),A0
move.b    #0x2,(A0)
movea.l   (-0xe,A5),A0
move.b    d4,(0x1,A0)
movea.l   (-0xe,A5),A0
move.b    d5,(0x2,A0)
movea.l   (-0xe,A5),A0
move.w   #0x1,(0x8,A0)

There are some optimization opportunities

It looks like the compiler didn't apply subexpression elimination for the pointer dereference.

[jotd]

okay but do you really need more speed on that game? Our elders knew that compilers were crap, so they wrote critical parts in assembly already.

if so, I suppose that one could disassemble, remove the useless instructions / write more efficient code, reassemble.

But first, you'd have to profile the code to see where you'd have the best gain, else it's a lot of work for unguaranteed results.

PS: great job with the RE of Populous nevertheless. Granted, re-making those games for modern platform has little interest as those modern platforms can already emulate the real game. Unless you add features (HD, extensions...) which is another story...

[ara]

Originally Posted by jotd

Granted, re-making those games for modern platform has little interest as those modern platforms can already emulate the real game

True. For me, it's just a leisure activity and a kind of archeology. It's fun to see how much game play they could squeeze into a few kbytes of code. If a remake or extended version were the goal, it would be more interesting to directly start from Populous 2.

[jotd]

Another useful thing when resourcing is you can figure out how data is done and create level editors for the original engine.