Is.. there anything new in there? I only recall making some experimental changes to handle unaligned .bss (since it turns out gcc selects the alignment of volatile sections as it likes) (which didn't seem to work), and nothing else in there looks new.

..unless someone else contributed a patch.
I made a bug fix last night relating to the .bss sections. It probably won't fix Ashbad's problem, but it may prevent something in the future.
Ah, so there is. Seems to be almost identical to the patch I made (just a mov.b while zeroing .bss instead of mov.l) but you added a nop after the bf. I didn't think that was necessary though, since bf has an implicit delay slot (bf/s to put that to use). What's your rationale for inserting that nop?
If you have jump instruction in the delay slot, the processor throws a slot exception. It's basically illegal syntax. I'm surprised the assembler didn't catch it.
I think the Assembler knows that and will automatically add the nop for you.
Tari wrote:
I'm concerned by the PC value. It shouldn't be trying to execute out at 810000A, since that's probably the .bss segment. (Sure would be nice if we knew what these error messages were really saying.) I hesitate to blame the toolchain for that, though.

When in doubt, I like to change the linker to ELF output (line 2 of prizm.ld -> OUTPUT_ARCH(sh-elf)) and examine the resultant file (main.bin IIRC) with objdump (maybe objdump -hs perhaps in addition to -d) to get a better feel for how the memory map looks.

There's a good chance you're smashing the stack, making one of your subroutines return to 810000A (likely where one of your arrays is placed) which, predictably, doesn't contain a sensible instruction so you get the access fault (seems that whatever's at that address attempts to do a word access to an odd address).
Seems unlikely as 0x0810000A is an address that is first invalid as it is part of the P0 area, but if it is referring to that PC as a physical address that is part of the OS stack which the code never touches unless there is an error.
Then it sounds pretty definite that a segfault or stack smash is occurring here to me. Ashbad, did you have a chance to try out some debug steps towards making this work?
0x08100000 is the virtual startaddress of any G3A's static RAM.
BTW: in the fx9860-OSes the static RAM was limited to 8k per G1A.
Hmm, lots of posts while I was asleep. Unfortunately, I haven't been able to do anything yet :/ I'll try to post a status on it later.
SimonLothar wrote:
0x08100000 is the virtual startaddress of any G3A's static RAM.
BTW: in the fx9860-OSes the static RAM was limited to 8k per G1A.
Now I thought 0x88160000 was the start address of the g3a stack and ox80F00000 was the start of the OS stack. When looking up 0x81000000 all I see is empty stack space which is denoted by $55


Edit: Yay, I'm an advanced newbie now!!! Laughing
z80man wrote:
Now I thought 0x88160000 was the start address of the g3a stack and ox80F00000 was the start of the OS stack. When looking up 0x81000000 all I see is empty stack space which is denoted by $55

0x88160000 is the start address of the g3a stack
0x880F0000 is the start of the OS stack
0x08100000 is the unique virtual address every G3A (and G1A) uses for the static RAM. The OS maps it to some free area of the physical RAM, when a G3A (or G1A) is invoked.
Qwerty.55 wrote:
If you have jump instruction in the delay slot, the processor throws a slot exception. It's basically illegal syntax. I'm surprised the assembler didn't catch it.

The assembler has no way of knowing how control flow will go. For all it knows (or cares), you just put that instruction in because it looks nice.

I'm well aware of how the processor deals with delay slots, but the documentation for bf seems to say that it dumps the pipeline and inserts nops when taking the branch rather than using the usual delay slot. Again, that's the difference between bf and bf/s. Indeed, the description for bf/s mentions the usual delay slot pitfalls, while that for bf does not.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement