Re: New datatype addition to gcc

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:


> Michael Meissner wrote:
>
> > Sriharsha <sriharsha.v@redpinesignals.com> writes:
>
> >>My h/w personnel says that there will be TWO RAMs in the processor,
> >>one is 8-bit addressible while the other is 16-bit addressible. If
> >>the compiler has to do 8-bit data load/store, it uses the 8-bit RAM
> >>and if it has something to do with 16-bit, it uses that RAM. This
> >>sounded bizzare to me but, thats what they say (or atleast I've
> >>never come across such stuff).
>
> (snip)
>
> > My take is you can't expect an ISO standard C implementation on such a
> > machine using two address spaces, one for byte accesses and one for
> > word, since structures can contain both types, and structures are
> > required to have all members adjacent.
>
> Structures are allowed to have padding for alignment. The only
> restriction that I remember is that a pointer to the structure is
> equivalent to a pointer to the first member. Past that, I don't know
> about such restrictions. Casting pointers to a different type and
> dereferencing them is not guaranteed to work, either.
>
> It would seem to me that it might just work.


No it won't. For example, if the memory space that you can do 16-bit
or higher memory operations is from 0x00000000 to 0x7fffffff, and the
memory space that you can do 8-bit only memory operations is from
0x80000000 to 0xffffffff, and you have the following structure:


                struct stype {
                                int a;
                                char b;
                } s1, s2, *p1;


you cannot put the bits for 'a' into one address space and the bits
for 'b' into the other, the bits must be contiguous. Otherwise things
like:


                memcpy ((void *)&s1, (void *)&s2, sizeof (struct stype));


won't copy all of the bits, as is specified in the standard.


Even if the address spaces have the same range so that you don't need
separate memory addresses, memcpy would not be cope with it. Consider
a union:


                union utype {
                                int a;
                                char b[sizeof (int)];
                } u1;


Most programmers would be astonished on such an implementation that:


                u.a = 'a';
                if (u.b[0] == 'a') {
                                printf ("Little endian\n");


                } else if (u.b[ sizeof(int)-1 ] == 'a') {
                                printf ("Big endian\n");


                } else {
                                printf ("Confused system!\n");
                                fflush (stdout);
                                abort ();
                }


would print confused system due to u.a and u.b being in separate
address spaces. Granted, the ISO C standard does not actually promise
that unions overlap, but the way most people use a union is to share
storage.


Also, with separate memory spaces, I don't see how you could implement malloc:


                p1 = (struct stype *) malloc (sizeof (struct stype));


How is malloc supposed to know it is also supposed to allocate space
in the other address space?


The only way I can see of supporting such a machine without resorting
to compiler dependent pragmas is to only put char values into the
alternate space that you are sure never have their address taken (ie,
statics and autos since you can determine at compile time whether an
address is taken, globals can't be done, since typically you don't
have information on whether other modules took the address). All
other chars would need to be put into the standard word oriented
address space, and use multiple instructions to extract and set them.
Alternatively, you could put everything into the byte memory and do
multi-word operations to get 16/32 bit values, but that perhaps is
more bizarre.
--
Michael Meissner
email: mrmnews@the-meissners.org
http://www.the-meissners.org

Return to the comp.compilers page.
Search the comp.compilers archives again.