CC65 compiled with “-O” for optimization- memory issues

[Yaron Nir]

Anyone has bad experience wit O option to optimize code?

 

I have encountered some issue with it.

I have a code that set parameters . If I comment out this code I see glitches appears on screen (display list gets messed up)

If the code is not commented - all well

 

If I remove the O option from compilation then everything is working both when Code is commented out or not commented at all.

 

Would like to hear your thoughts about it.

 

What does this option do anyways ? Does it change memory layouts ?

[baktra]

It depends. There are multiple possibilities

 

1. The -O option can result in longer but faster machine code. The longer machine code might overlap with your display list or screen memory.

2. There is a problem in your original code and it just somehow happens to work with non-optimized code

3. There is a bug in the optimizer

 

I have never experienced a problem with the -O option (provided that it is only -O, not -Os). All games I have written with CC65 have the -O option set.

 

You can get more information if you share your source code.

Edited October 2, 2018 by baktra

[Yaron Nir]

As for bullet #1

I have manage to set a location fix for the starting address and then set all the memory occupations below that address and made sure there were no overlaps.

 

As for other 2 bullets, well the easiest thing is to

Blame the optimizer

[Wrathchild]

Also useful is to use the -S option on the cl65 command line to retain the generated assembler files with and without the -O flag and then diff those

[baktra]

As for bullet #1

I have manage to set a location fix for the starting address and then set all the memory occupations below that address and made sure there were no overlaps.

 

As for other 2 bullets, well the easiest thing is to

Blame the optimizer

 

Then you can try older versions of cc65 to validate your theory.

Please consider sharing your code. Discovering a re-creatable defect in cc65's optimizer would be invaluable for cc65 developers.

[Yaron Nir]

 

Then you can try older versions of cc65 to validate your theory.

Please consider sharing your code. Discovering a re-creatable defect in cc65's optimizer would be invaluable for cc65 developers.

 

well, it is definately an issue with the -O option.

i've added some more C routines to my code and then the problem stopped. it didn't matter if the previous code was commented or not, it was working fine.

so there is point where the -O fucks up memory especially my DL.

 

unfortunately, i can't post my code as i am working together with another atari guru on a commercial game......

let me know if you have specific question in order to trace this issue so i can try and help

[Yaron Nir]

Also useful is to use the -S option on the cl65 command line to retain the generated assembler files with and without the -O flag and then diff those

 

yes, that's a good point wrathchild.

i have progress with me code so i can't roll back now, but if encountered again, will definately do that....

[baktra]

 

yes, that's a good point wrathchild.

i have progress with me code so i can't roll back now, but if encountered again, will definately do that....

 

Don't you use any kind of SCM? :-). It is a commercial game, after all.

[ivop]

As for bullet #1

I have manage to set a location fix for the starting address and then set all the memory occupations below that address and made sure there were no overlaps.

 

Perhaps you could check if the linker actually did what you asked? (i.e. put DL data etc. on a fixed location and no other load segment overlaps)

 

I wrote a small CLI utility I use pretty often. Perhaps I can cross-compile a Windows version if that's what you need, otherwise just compile with gcc. Sample output:

$ a8inspect AUTORUN.SYS 
$207d - $20c5
$2100 - $211c
$2122 - $2271
$3000 - $3bb4
$4000 - $5bc5
$0600 - $06bd
$02e2 - $02e3	INITAD: $0624
$0080 - $0085
$226f - $2e3c
$02e0 - $02e1	RUNAD: $0695

Edit: BTW bonus points if somebody can guess which AUTORUN.SYS this is

a8inspect.zip

Edited October 2, 2018 by ivop

[Yaron Nir]

Ivop that is an excellent tool, I was looking for a tool exactly like that as the map file only generated the things above the starting address...

[Wrathchild]

Eh? Don't you use the Altirra debugger?

 

[Yaron Nir]

Eh? Don't you use the Altirra debugger?

 

debug.png

Well, altirra debugger is another option ....

[baktra]

 

Perhaps you could check if the linker actually did what you asked? (i.e. put DL data etc. on a fixed location and no other load segment overlaps)

 

I wrote a small CLI utility I use pretty often. Perhaps I can cross-compile a Windows version if that's what you need, otherwise just compile with gcc. Sample output:

$ a8inspect AUTORUN.SYS 
$207d - $20c5
$2100 - $211c
$2122 - $2271
$3000 - $3bb4
$4000 - $5bc5
$0600 - $06bd
$02e2 - $02e3	INITAD: $0624
$0080 - $0085
$226f - $2e3c
$02e0 - $02e1	RUNAD: $0695

Edit: BTW bonus points if somebody can guess which AUTORUN.SYS this is

 

 

This is a good utility (there are similar round).

I would like to have it as an Windows Explorer extension. Hover mouse over a .xex file and see listing of the segments.

[antrykot]

 

I wrote a small CLI utility

 

Unfortunately your code is not correct.

 

.

fopen(argv[1],"r")

To read binary files use binary mode. You should use binary mode even if you are on a POSIX compatible system as this cost you nothing and gives you portability.

 

.

fgetc(fp) | fgetc(fp)<<8

Evaluation order of subexpressions is unspecified, you don't know which of the two fgetc calls will be executed first.

 

.

while (!feof(fp)) {

This is not the right way to write a loop that reads the entire file.

 

.

fseek(fp, end-start+1, SEEK_CUR);

This requires binary mode to work, it has undefined behavior otherwise.

Edited October 3, 2018 by antrykot

[Irgendwer]

This is a good utility (there are similar round).

 

 

Yes, like "ataricom", which I use: http://www.horus.com/~hias/atari/

[ivop]

 

Unfortunately your code is not correct.

 

.........

 

First, I wrote this small utility in like five minutes and it works for me and I didn't intend it for distribution in the first place. "Binary mode" has been deprecated since C89, which is 29 years ago. As for portability, the only current compiler/libc I know of that needs it is VC++, which isn't a proper C compiler (C++ is not strictly a super set of C, which MS still seems to think).

On the evaluation order, you are right, but I didn't care at the time. See the first line of this answer. Similar, while (!feof(fp)) can detect the EOF too late, but in that case your A8 file is broken anyway.

[Yaron Nir]

so, it is definately an issue with the -O option as i encountered it again progresing my code.

it seems to be fucking up my display list only.

witout the -O all works well.

 

again, i appologize for not being able to post the code.....

[antrykot]

 

"Binary mode" has been deprecated since C89, which is 29 years ago.

No, it isn't deprecated, and never was. The 'b' flag is ignored on POSIX systems, but it is essential in other implementations.

[sanny]

so, it is definately an issue with the -O option as i encountered it again progresing my code.

it seems to be fucking up my display list only.

witout the -O all works well.

 

Still, could be a problem in the compiler or a problem in your code.

 

Now, that you can reproduce it again, you could

 

• try to remove parts of your program to get a really simple example code where the problem happens. So small, that you don't publish IP when you send it to the cc65 developers. That's btw. the preferred way to send compiler bug reports.
• Use the debugger of an emulator (Altirra or Atari800) and set a breakpoint to memory write to the memory of the display list. When the bp triggers, use the map file to figure out where it happens.
• Send me the source code (or link to it) and I'd take a look. I won't share your source code to anyone else.

 

regards,

chris

[Yaron Nir]

try to remove parts of your program to get a really simple example code where the problem happens. So small, that you don't publish IP when you send it to the cc65 developers. That's btw. the preferred way to send compiler bug reports.

 

 

in the previous time it was fucked up, the code that was causing it was :

// DEBUG
xPos = 114;
yPos = 66;
//DEBUG

When this code was opened , all worked well, when this code was commented out , display list was fucked up. perhaps it was something else i've added that caused the optimzer to fuck up display list when this code was commented out...who knows....

 

 

• Use the debugger of an emulator (Altirra or Atari800) and set a breakpoint to memory write to the memory of the display list. When the bp triggers, use the map file to figure out where it happens.

 

 

 

about that. how can i set a break in CC65?

i tried using this command:

asm("brk")

but nothong happens in altirra??

i want to be able to debug break within the cc65 code

 

• Send me the source code (or link to it) and I'd take a look. I won't share your source code to anyone else.

   

  this project is under wraps and also invovles other great developer.

• i must keep it that way, so no code publish nor share for now. appologies.

[Wrathchild]

Shouldn't "other great developer" therefore be guiding you on this?!

 

by removing two lines of code then other code & data is going to have shifted in memory. Compare before and after label / listing files to ensure everything is in place where you expect it.

 

Read things!!!! Especially the Altirra manual.

Debugger in Altirra is enabled by using the F8 key.

You do not need to inject BRK's into your code as Altirra can detect and import the label file and so you can use "bp MyRoutine".

Check ".help bx" too in Altirra. As advised already you can check a write to a specific area of memory, e.g. "bx "write>=$1000 and write<=$1004"

[baktra]

You can post at least your linker.cfg file.

I hope your DL is protected against crossing 1 KB boundary

[Yaron Nir]

Shouldn't "other great developer" therefore be guiding you on this?!

 

by removing two lines of code then other code & data is going to have shifted in memory. Compare before and after label / listing files to ensure everything is in place where you expect it.

 

Read things!!!! Especially the Altirra manual.

Debugger in Altirra is enabled by using the F8 key.

You do not need to inject BRK's into your code as Altirra can detect and import the label file and so you can use "bp MyRoutine".

Check ".help bx" too in Altirra. As advised already you can check a write to a specific area of memory, e.g. "bx "write>=$1000 and write<=$1004"

Its hard to explain but in short , that other great developer is an asm guru and less CC65 guru

The game is written in asm and also in native CC65

Its a bit complicated like a relationship

 

I will try the altirra BP... Tnx wrathchild

[Yaron Nir]

You can post at least your linker.cfg file.

I hope your DL is protected against crossing 1 KB boundary

I do not use one, user the Atari.cfg default file

I do however use the command line to set starting address

And to your question , yes the DL doesnt pass the 1K boundary

[sanny]

Yaron,

 

your posts aren't really helpful. What was the intention of your original message? Do you want any help?

 

Answering to your initial post: Yes, -O can have problems. After all it generates different code. OTOH, many people seem to use it without problems. So no one can tell what is at fault.

 

So, if you want to nail down the problem at hand, either debug it yourself (the second bullet in my last post), or give us something that doesn't work so we can debug it.

Everything else is just blahblah...

 

regards,

chris