Re: New targets to Binutils for H8 series

["D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>]

Hi Nick,

> 
> Hi Venky,
> 

> > I think it would be a good idea to add a target, say
> > -msim, so that the code is generated for simulated target only.
> 
> Generally speaking this is a bad idea.  Simulators ought to be able to
> simulate code compiled for real targets.  You should not have to
> compile a program for a "simulator-only" target.
> 

I do tend to agree with you on that. It may not be bad but yeah, its 
ugly. Anyways, I was not trying to change code generation, only adding 
an option for adding some extra startup code.

> 
> > In the context, I was actually trying to include commandline support
> > to the simulator and so would have to setup the stack with the
> > commandline arguments in crt0.S. I didn't think it would be a good
> > idea to add the code to the default implementation, by adding the
> > target, we could write any simulator specific code inside a #ifdef
> > __SIMULATOR__ kind of structure, similar to the ARM implementation.
> 
> Are you saying that the default target execution environment for H8300
> binaries does not have any way of obtaining its command line ?  So you
> want to invent one that will work with the simulator ?  If so, then I
> can understand your desire to have a "-msim" switch, but I still think
> that it is a bad idea.  Instead I would suggest that you do something
> similar to the mechanism used in newlib for the ARM.
> 
> In the file newlib/configure.host, for the h8300 entry, add an new
> define, eg -DSIMULATOR_ARGV_SUPPORT and then test for this in crt0.S.
> You still end up with a customised-for-the-simulator crt0.o file, but
> these do tend to be execution environment specific, and normally a
> user would use a spec file to select the correct crt0.o for their
> execution environment.

Well, that is one of the ways, and in fact, I would like to adopt this 
method. This approach is actually similar to the -msim option above, 
just that this would result in a change in newlib, whereas that would 
have been global. Thank you for this suggestion.

H8300 has some other problems, in ARM there seems to be 0x0000 - 0x8000 
memory that is free, so they store the commandline string at 0xf00L. In 
the H8300 linker script, it is a little ambiguous.

MEMORY
{
        /* 0xc4 is a magic entry.  We should have the linker just
           skip over it one day...  */
        vectors : o = 0x0000, l = 0xc4
        magicvectors : o = 0xc4, l = 0x3c
        ram    : o = 0x0100, l = 0xfdfc
        /* The stack starts at the top of main ram.  */
        topram : o = 0xfefc, l = 0x4
        /* At the very top of the address space is the 8-bit area.  */
        eight : o = 0xff00, l = 0x100
}

Now, there is this 8-bit area, from 0xff00, having 256 bytes, I could save 
the commandline string here and set the pointers on the stack in crt0.S. 
But this would render the 8-bit area, fully occupied leaving no free space  
(I guess, this area is free space). If some new requirement for free space 
comes, then, it would be a problem :-(. And if someone changes the linker 
script to enable more simulator memory, then, a change will also be required

in crt0.S. But I guess, this is the best possible strategy available to us.

A question about calling conventions, the calling conventions for variable 
arguments is not clear. For a commandline like, 

a.out arg1 arg2 arg3 ...

Register 0 should have 4, the first argument to main.

Register 1 should contain a pointer to 'a' in the commandline string.

Should Register 2 have pointer to arg1?

What should the stack be?

Should it be pointers to : 

<--- Top of the stack
arg1      ^
arg2      |
arg3      | Decreasing Address
.         |  
.
.
<--- Bottom of the stack

Or

a.out     ^
arg1      |
arg2      | Decreasing Address
arg3      |
.
.
.

Or

arg2      ^
arg3      |
.         | Decreasing Address
.         |    
.

I am pretty confused about this, could someone elaborate this 
point. Any useful hints, I have seen the Hitachi calling 
conventions on their website, there is no mention of calling 
conventions for variable arguments.

> 
> Cheers
>         Nick
> 

Thanks and Regards,

Venky