HomeForumsWhat's newResources 
 
 
sh asm syntax question
RadSil - Jan 1, 2003
  RadSil Jan 1, 2003
I haven't posted at SX forever but as soon as I ran into my problem, I figured I would take it to you guys.

I'm screwing around with SBL6, and I wanted to recompile it under gcc 3.2 (I figure with the improvements since ~2.7, it wouldn't hurt). All the C code builds mostly fine, with a few insignificant warnings, but the asm's syntax isn't correct. I started in on converting it to the apparently newer syntax AS wants and I'm worried that I may be breaking the code. A few questions, as I don't know SH asm at all:

1) AS chokes on MOV.L Rx, Ry but just mov Rx, Ry is okay. Are these equivalent?

2) I replaced .EXPORT with .global. Are these the same directive?

3) There is a directive reading something like

.SECTION SEGA_P, CODE, ALIGN=4

I replaced this with

.section .code

.align 4

What is section SEGA_P (or some sources, SEGA_C)?

4) And lastly, variables. There were some .RES.L / .RES.W pseudo-ops I replaced with .long and .word and .DATA.L and .DATA.W that I also replaced with .long and .word. This is where I'm afraid I might have broke something.

I made backups, so I'm ready to fix the source if necessary. Is there any good sh-coff-as specific documentation out there? KPIT's GNUSH doesn't come with any. Thanks in advance!

 antime Jan 1, 2003

  
	
	

		
		

			Originally posted by RadSil@Jan. 01 2003, 4:11 pm



1) AS chokes on MOV.L Rx, Ry but just mov Rx, Ry is okay. Are these equivalent?


I believe so. The SH architecture doesn't support anything but dword-sized reg-reg transfers, so a "mov.l" is redundant. Hitachi's own syntax is MOV Rm, Rn and GAS tries to support the vendor syntax as far as possible.


  
	
	

		
		

			2) I replaced .EXPORT with .global. Are these the same directive?


In newer binutils, .export is a HPPA-specific directive. In older binutils, .global and .export were synonyms.


  
	
	

		
		

			3) There is a directive reading something like



.SECTION SEGA_P, CODE, ALIGN=4



I replaced this with



.section .code



.align 4



What is section SEGA_P (or some sources, SEGA_C)?


Probably something they defined in their link scripts. As you probably know, you can define your own sections and direct the compiler/assembler/linker to put your data in those sections. This is needed for eg. overlays and to put code/data in the lower RAM region.


  
	
	

		
		

			4) And lastly, variables. There were some .RES.L / .RES.W pseudo-ops I replaced with .long and .word and .DATA.L and .DATA.W that I also replaced with .long and .word. This is where I'm afraid I might have broke something.


That should be OK. The .RES.n pseudo-ops reserved room for uninitialised data, but I'm not sure if there's a 1:1 replacement. The .data.size is identical to .byte, .short and .int/.long.

If there's large amounts of uninitialized data you should make sure it gets placed in the .bss section so it isn't included in the binary image.


  
	
	

		
		

			Is there any good sh-coff-as specific documentation out there? KPIT's GNUSH doesn't come with any. Thanks in advance!


The GNUSH distro should come with a "Using as" document, which is basically this... in one page. There's very little SH-specific about as, but you can find it under section 8, "Machine Dependent Features". You also shouldn't have any trouble finding old binutils documentation on the net to use as reference.

 RadSil Jan 1, 2003
Thanks a lot. So: I still need to add a .section for SEGA_P or SEGA_C (I'll check the linkscripts...) and I need to make sure that things like math tables, long sections of initialized data are in section .bss?

 antime Jan 1, 2003
No, it's the opposite: initialized data goes into .data, uninitialized data goes into .bss. .bss is also cleared by the startup code.

 RadSil Jan 1, 2003
Okay, I thought that was it, because the stuff I read about clearing the bss would make no sense otherwise

I've run into some trouble on one particular source file... it's "SPR_3A1.SRC" in the segalib/spr directory. There are some undefined symbols of some sort in there which I might be able to get worked out, but my real problem is that there seems to be no newer equivalent of the SIZEOF operator, at least not one that I can find in the as docs. The code tries to (from my educated guess) take the total size of the "Work" section and subtract it from the stack pointer (I think?). Later in the code it puts (adds) it back.

Also, I think that the SEGA_C and SEGA_P are sections with subsections like CODE... I have to get this right or I will probably be dealing with linker errors in the future if I don't.

The above mentioned source has a ".SECTION SprSurface,DUMMY" in it which I just changed to ".section SprSurface". I'm really lost here...

 antime Jan 1, 2003
Hmm, I really don't know about those. SIZEOF is a linker directive, but I have no idea on how to get the assembler to understand it. You're probably right about the SEGA_C and SEGA_P sections, but without the right linkscript it's going to be tough to get things right. You could try checking the .A and .LIB files in the LIB directory and see what symbols are defined to where and try to recreate the script, as it seems the library was intended to be compiled with a different compiler distribution than the one available.

 antime Jan 1, 2003
Found some more info:

Those .RES directives were actually GASP (assembly preprocessor) directives, which were converted to .space directives. .DATA.size were converted to .byte, .short and .long. I believe GASP is obsoleted now, but I don't know if its functionality has been integrated into GAS or if you're just supposed to use CPP instead.

Those *.SHC files found in the SBL tree are commandline option files for Hitachi's C compiler. It apparently has single-letter section names by default. Sega set up the following aliases:

p = SEGA_P = program section

c = SEGA_C = constant data

d = SEGA_D = initialized data

b = SEGA_B = bss

I'll add more info as/if I find it.

 antime Jan 1, 2003
It seems that I was completely on the wrong track. The directives (and the sources) are for Hitachi's tools. I've uploaded the Hitachi manuals to my page, so you can check this out for yourself.

If you do manage to convert the libraries to GCC it would be interesting to do a performance comparison between the two. The Hitachi-compiled libraries may be old, but they might still outperform those compiled with a new GCC.

 RadSil Jan 2, 2003
So the assembly sources were never meant to be compiled with AS, or any other GCC preprocessor? Interesting. That's probably why I can't find a substitute for SIZEOF, but I can always just add up the size of the section, as it's only used twice. Thanks for the Hitachi tool docs, I'll have to look at them. Oddly enough though, the sources are listed in the GCC makefile? Why? I think the makefile originally cited GASP as the assembler, I just replaced it with sh-coff-as and moved on. Guess I may have a little work in front of me.

 antime Jan 2, 2003

  
	
	

		
		

			Originally posted by RadSil@Jan. 02 2003, 4:18 pm



So the assembly sources were never meant to be compiled with AS, or any other GCC preprocessor?


I think Sega was aiming for the sources to be buildable both with GNU and Hitachi tools, but they certainly seem to use the native Hitachi format. GASP does/did convert most of the Hitachi-sms to GNU format which is in line with GCC's goal of being a drop-in replacement for the system tools.


  
	
	

		
		

			That's probably why I can't find a substitute for SIZEOF, but I can always just add up the size of the section, as it's only used twice.


You could also try defining a symbol in the link script that is the SIZEOF the relevant section. SIZEOF remains a valid GNU ld directive. Another option is to place symbols before and after the section and subtract the addresses.


  
	
	

		
		

			Oddly enough though, the sources are listed in the GCC makefile? Why? I think the makefile originally cited GASP as the assembler, I just replaced it with sh-coff-as and moved on.


As I said, I think the sources were meant to be compatible with both. There are some mentions in various places (eg. the SGL release notes) of the possibility to use either compiler. Given the performance of GCC Hitachi's compiler would have been the compiler of choice, but it would also have been an extra expense. Besides, SN Systems used GCC which would be an extra incentive to be GCC-compatible. (As a side note, the GASP included with the devkits seems to be a plain AWK script which processes the sources and calls AS.)


  
	
	

		
		

			Guess I may have a little work in front of me.


Keep us posted on your progress!

 vbt Jul 24, 2003
I've recompiled some libs of SBL6 without problem and use them with a SMS Emu in full SBL6 but I didn't notice some win of spped. Also It seems latest gccsh produce smaller code but gasm (for files in ASM) makes bigger code than object in SEGA original libs. Also I tried with ASMSH but didn't manage to assemble something (too many options for me).