Re: .comm size problem

["Svein E. Seldal" <Svein dot Seldal at solidas dot com>]

Hello Nick,

Nick Clifton wrote:
> Does the tic4x port of gcc support the notion of an 8-bit object ?
> Ie is "sizeof (char) == 8" ?

No. sizeof(char)=sizeof(long)=1unit=32 bit. The target is totally
unaware of less quantities than 32-bit. One increase in the address
pointer increases the data 32-bit up in the target's memory.

This property is really the whole source of the problem; .comm refers to
n quantities of 8-bits information, i.e. bytes. This is normally
analogous to n increases to the address-pointer.

Now if we transfer the latter definition to the tic4x target, we want n
increases to the address-pointer when .comm are used. To acheive this,
the linker must allocate n*4 (host) bytes because of the sizeof(char)
property.

> Note - there is no need to replicate the functionality of s_comm().
> You can just change the size parameter as necessary in your own .comm
> or .octet_comm implementation and then call s_comm() directly.
>
> If you do not ever need to support 8-bit .comm directives then option
> a) when it just overrides the standard .comm behavior should be OK.

Yes, this is what I want do to too, but there is a catch to this method: 
If a (l)user uses .comm in a source file. Say he want to allocate a 16 
address area and writes .comm 16. Internally gas translates this to a 
16*4=64 bytes allocation as you propose. If the user now dumps the 
object file with objdump or nm, he will be told that the size of the 
comm is 64, not 16 as he wrote. Again, bytes is an unknown unit in 
tic4x-world.

If we, however, make the *4 multiplication in the linker as proposed, 
everything will be correct. The user will always refer the comm size in 
sizes of lwords (i.e. elementary address increases), not bytes.

> I agree that option b) appears to be more aesthetically pleasing, but
> it sounds as though underneath everything is still being handled in
> terms of 8-bit quantities and you are just concealing this fact when
> reporting information to the user.  I think a better solution would be
> to admit that data is still measured in 8-bit units, even if the
> target requires that *all* data sizes be a multiple of 32-bits.

Again. The tic4x users wont expect data to be handled in 8-bit
quatities, but in the units handled by the target (which is represented
as 4 8-bit units).


Svein