Page 5 of 57

Posted: Sun Mar 09, 2008 2:57 pm
by Edge-`
I saw this last week at some point, fantastic Kaneda!

Posted: Mon May 05, 2008 2:38 pm
by tails92
I'm not sure if this was discovered earlier, but I've found a serious bug in this devkit. I'm using version 0.4, with the bundled gcc.

Code: Select all

/* This code doesn't work, while it should */
int a = -1;

int main()
{
	return 0;
}
If a global variable is given a negative value at startup, ld gives the following error:

Code: Select all

ld: address 0x49328 of rom.out section .data is not within region ram
Make exits then.

Posted: Mon May 05, 2008 2:58 pm
by Sik
GCC issue. Initialized global variables will never work (either they're hardcoded in the ROM or GCC expects the value to be initialized before main() and it isn't), and for uninitialized ones to work you need to somehow tell the linker to store them in the RAM area (0xFF0000), through no idea if the devkit does this already. Local variables work in the stack so they never have problems.

The only way to get through it would be a specialized compiler :/

Posted: Mon May 05, 2008 4:41 pm
by tails92
You are right. Initializing a global variable with 1 doesn't work, too.
I remembered this being an issue with SGCC but not with GCC, I guess I was wrong.

Posted: Mon May 05, 2008 4:56 pm
by Sik
It's an issue with all compilers. They expect the values to be initialized before calling main(). Since there's no stub program that does it (the only stub thing used is normally just the header), compilers fail to do the right thing. Which is why I say only a specialized compiler would do, because it would require a compiler that knows about this issue and does the initialization by its own before calling main().

I guess GCC can be modified to support that through, right?

Posted: Mon May 05, 2008 5:02 pm
by TmEE co.(TM)
somebody write a translator (like BasiEgaXorz - BASIC to ASM)

Posted: Mon May 05, 2008 5:07 pm
by Sik
That's the exact definition of a compiler >_>

I would make a C compiler, but it would be a lot of work and I don't feel like doing so, as well as it would have to be very optimizing, through we could make one in group if you want. But still, modifying GCC is also a good alternative, as we already have the compiler :P

Posted: Mon May 05, 2008 5:21 pm
by Shiru
Why you need to initialize global variables? I think, it's just somewhat bad program design. I can't imagine where it can be really needed.

Posted: Mon May 05, 2008 5:26 pm
by TmEE co.(TM)
Translator and compiler are different... first translates code in one language to another, BEX does BASIC to ASM(which is then assembled to binary), second does code directly to binary.

Posted: Mon May 05, 2008 5:33 pm
by Sik
You're mixing compiling with building. A compiler just converts from one language to another.

Preprocessor -> Compiler -> Assembler -> Linker :P

Posted: Mon May 05, 2008 5:35 pm
by TmEE co.(TM)
my QB compiler doesn't generate ASM code... it will make a OBJ, which is a binary, which you'll feed to a Linker which makes that OBJ ready to run in my case in MS-DOS environment...

Posted: Mon May 05, 2008 5:40 pm
by Sik
Also it doesn't have a preprocessor. I've just listed all possible processes, and as you can see, compiling is just one of them. The entire group of actions that make the final executable is called building.

Posted: Mon May 05, 2008 8:13 pm
by Chilly Willy
The problem is that anything with data, be it code or not, MUST go into the ROM. We're not loading a file off a hard drive, after all. So if variables are initialized with a value to start, they HAVE to go into the rom. But they are variables and should go into the RAM. So you'd need to have a way to put the initialized contents into the ROM, then when the ROM is started, copy that to the RAM address used in linking.

Posted: Mon May 05, 2008 8:22 pm
by Sik
And that's what the stub program should do, but there isn't such a program running before main(). Also compilers assume the program will be run from RAM, so anything can be modified. This isn't the case. This is the main reason they fail to work with global variables properly.

Posted: Fri May 09, 2008 2:03 am
by Shiru
Stef wrote:I realised i never replied your last post.
I think the 32 bits modulo operation is buggy, i guess you're doing it on 32 bits sized variable ? I rarely use modulo but i never meet any problem with division. I'll check the 32 bits modulo code in sega.s file, maybe a stupid bug.
I did some tests today.

I downloaded and setup kit (only changed path where needed) once again to make sure that nothing broken after my previous try. I made only one change in sega.s - replaced line 132 from 'jmp start' to 'jmp main' (I don't use kit libs, like I said).

I made small program which changes palette randomly in loop (to see if program hangs). When I added some test lines in code.

First, I tried unsigned short variable. It have some value on start (i tried different initial values).

If I do operations:

i=(i+1)%10; //hangs

i++;
i%=10; //works

i=(i+1)/10; //hangs too

i++;
i/=10; //works

Then I tried unsigned long variable. Things even worse:

i%=10; //hangs
i/=10; //hangs

I also tried signed int and long, tried to declare variable inside 'main' or as global variable. Results are same.

So, if I did nothing wrong, it means that there is serious problems with kit.