Planet Bob

Damn, that's rather surprising that C++ actually takes up fewer lines of code than ASM could. Question is, though, how tightly-optimized can it get compared to ASM for a specific processor?

Damn, that's rather surprising that C++ actually takes up fewer lines of code than ASM could.

 

Why is it surprising that C code takes fewer lines than .asm? Isn't that the whole point of using languages like C in the first place?

There's a couple of things that make C++ more efficient regarding the # of lines you need to type:

 

- You don't need to take care of registers and their usage.

- you don't need to manually handle RAM usage.

- you can just declare any variable you need, where you need it.

- you can pack more than one (math) operation into a line.

- C constructs are more powerful: A for-loop for example is only a single line.

 

Here's for example the initialisation of the dungeon in ASM:

	 LDA #$00
	 STA pDstTemp
	 TAY
	 LDA #$10
	 STA pDstTemp+1
L9D25	LDA #%00111111
L9D27	STA (pDstTemp),Y
	 DEY
	 BNE L9D27
	 INC pDstTemp+1
	 LDA pDstTemp+1
	 CMP #$30
	 BNE L9D25

 

And the same bit in C:

for(int i=0; i<64; i++)
	for(int j=0; j<128; j++)
		dungeon[i][j] = TILE_FOG;

 

A few bits aside, I found the C code to be way more elegant and managable, I actually became a "fan" of C all over again

 

The only thing I found that C can't do without code trickery is replacing the 8-Bit rotation opcodes (ROR/ROL).

 

And, since I kinda made a very straightforward port, there's a couple of very ugly gotos in the code. In real life I'd never goto into(!) and out of an if construct for example:

if((Room2[SIDE_LEFT] < 2) || (Room2[SIDE_RIGHT] + 3 > 127)
|| (Room2[SIDE_TOP] < 2) || (Room2[SIDE_BOTTOM] + 3 > 63))
{
CreateRoomFailed:
 if(--iTries > 0)
	goto TryAgain;
 else
 {
	getRandomRoom();
	goto NextRoom;
 }
}

 

In fact I'm already surprised that it seems to work as intended

Why is it surprising that C code takes fewer lines than .asm?

It would be surprising if it would be the other way around.

 

The much more interesting question is, how large is the compiled result?

Why is it surprising that C code takes fewer lines than .asm?

It would be surprising if it would be the other way around.

 

Actually the comparison is unfair anyway. When everything is properly wrapped in brackets, I think you can even make it an (admittedly very long) one-liner in C

 

The much more interesting question is, how large is the compiled result?

 

Surprisingly small with 24K, considering that it is a full-blown WIN32/MFC Dialog based application.

 

(Part of why it is so small though is that I'm stuck with the students license of VC++6.0 at home, which doesn't allow static linking of the MFC )

Surprisingly small with 24K, considering that it is a full-blown WIN32/MFC Dialog based application.

Nah, I am only interested in the 471 lines. Visual Studio allows you to output the assembly code. Then it should be easy to count the bytes.

Surprisingly small with 24K, considering that it is a full-blown WIN32/MFC Dialog based application.

Nah, I am only interested in the 471 lines. Visual Studio allows you to output the assembly code.

 

Then it should be easy to count the bytes.

 

Ah ok, got you now!

 

IIRC the generator requires something like 1280 bytes of the 8-Bit cartridge. I'd assume my C++ version would use 2-3 times as much. I'll try to get the precise numbers for you tonight

 

Still: I certainly didn't care about memory usage for the port, so I may have some totally sub-optimal passages regarding that. Also, do you want me to compile it "normal" or with "minimize size"?

 

Maybe someone with too much time at hands is interested in porting it to a plain C version for CC65, just to see what size the generated 6502 binary would have then

Still: I certainly didn't care about memory usage for the port, so I may have some totally sub-optimal passages regarding that. Also, do you want me to compile it "normal" or with "minimize size"?

Minimize size would be interesting, especially because the assembly code seems pretty unoptimized.

 

Though Visual C++'s compiler isn't a good example of an optimizing compiler at all.

Minimize size would be interesting, especially because the assembly code seems pretty unoptimized.

 

Well, the difference between normal and optimized was 1 single byte. I was almost expecting this, considering that the code only does lowest level char operations.

 

I've been too lazy to sum up the sizes of all subroutines, since VC++ seems to be spreading them throughout memory, so I've been just comparing the largest "CreateDungeon" routine in both versions, which makes a little over 50% of the code:

 

6502: 628 Bytes

VC++: 1767 Bytes (1766 minimized)

 

Pretty much matching my prognose

I'm pretty sure there's still a bunch of minor and major errors in it

 

Slowly getting there... already eliminated 1 major and 2 minor errors.

 

It's kinda fun: I'm parallel-debugging both binaries step by step, one with VC++ and the other one with Atari800Win PLus 4.0, constantly comparing the results on both sides

I'm pretty sure there's still a bunch of minor and major errors in it

Slowly getting there... already eliminated 1 major and 2 minor errors.

 

I updated the ZIP package. The current binary is almost there. It properly does the first couple of rooms, but is still getting off track after a while. I think probably one of the the border checks is still off, or some comparison doesn't properly take the carry bit into account, taking a false branch on equal values or something like that. Hopefully I can finish it tonight