Re: How does C cope if architecture doesn't address bytes?
From: Richard Bos (rlb_at_hoekstra-uitgeverij.nl)
Date: 11/18/04
- Next message: Jhon smith: "Re: Learning C from old books ??"
- Previous message: Alan Balmer: "Re: [META] unanswered questions"
- In reply to: Dave Vandervies: "Re: How does C cope if architecture doesn't address bytes?"
- Next in thread: Gordon Burditt: "Re: How does C cope if architecture doesn't address bytes?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 18 Nov 2004 15:25:38 GMT
dj3vande@csclub.uwaterloo.ca (Dave Vandervies) wrote:
> In article <419c5588.229587426@news.individual.net>,
> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
>
> >Well, the implementation is allowed to use whatever magic is available
> >to it. For example, TTBOMK it's legal for it to scan the statement in
> >which the malloc() call occurs, figure out the type of the pointer which
> >it is assigned to, and instead of writing CALL (malloc), @ACC, @PTR to
> >the object code, write CALL (mallocalign), @ACC, @SIZ, @PTR. However...
>
> To handle malloc alignment in the compiler rather than the library in
> the general case, the implementation magic would have to be more magical
> than that.
Hmmm... I was rather imagining an implementation handling malloc
alignment in the implementation, rather than in either part of it. If
compiler and library are so strictly separate that there is no
communication between them, you do lose a lot of these optimisation
tricks, that much is true.
> void *debug_malloc(size_t size,char *file,int line)
> {
> void *ptr=malloc(size);
> if(global_params.debug_file)
> fprintf(global_params.debug_file,"Malloc %lu bytes at %s:%d: Got %p\n",(unsigned long)size,file,line,ptr);
> return ptr;
> }
> --------
> The alignment this call to malloc needs won't be known until run time,
> and the compiler won't know when it's compiling code that calls this
> function that it needs to know the alignment requirement.
Certainly; but it's also quite legal to apply optimisations when you
know you can, and leave them out when you can't determine their
validity.
> I believe it's also legal to do something like this:
> --------
> int i;
> short *s;
> double *d;
>
> s=malloc(sizeof *s * sizeof *d);
> for(i=0;i<sizeof *d;i++)
> s[i]=42*i;
>
> /*Is direct conversion short * -> double * allowed to do The Wrong Thing?
> I suspect it is, but forcing the conversion to go through void * is,
> if I'm not mistaken, required to get it right.
> */
> d=(void *)s;
I'm not sure. The Standard says
# The pointer returned if the allocation succeeds is suitably aligned so
# that it may be assigned to a pointer to any type of object and then
# used to access such an object or an array of such objects in the space
# allocated (until the space is explicitly deallocated).
It is possible to read this as saying that the pointer must be used for
a single type of object, IMO. (Barring unsigned char aliasing, of
course.)
Richard
- Next message: Jhon smith: "Re: Learning C from old books ??"
- Previous message: Alan Balmer: "Re: [META] unanswered questions"
- In reply to: Dave Vandervies: "Re: How does C cope if architecture doesn't address bytes?"
- Next in thread: Gordon Burditt: "Re: How does C cope if architecture doesn't address bytes?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
