This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Smob documentation



The compiler can't change the order of calls to other functions, so
this reordering won't happen.

I'm sure there are legal optimizations that would break my code.  But
we're already living beyond the law by using conservative GC at all.
What's worth worrying about is actual observed optimizations that
break code.  When we find those, we can decide what to do about them.



> Let's have a look at what cpp generates:
> 
>    image->name = ((( 16 )<<9)+0x174L)  ;
>    image->update_func = ((( 16 )<<9)+0x174L)  ;
>  
>    { if ((6 & (int)( scm_freelist )) )  image_smob  = scm_gc_for_newcell();	else {  image_smob  = scm_freelist; scm_freelist = (((scm_cell *)((  scm_freelist  ) ))->cdr) ;	++scm_cells_allocated; } } ;
>    ((((scm_cell *)((   image_smob   ) ))->cdr)  = (SCM)(  image )) ;
>    ((((scm_cell *)((   image_smob   ) ))->car)  = (SCM)(  image_tag )) ;
>  
>    image->name = scm_string_copy (name);
>    image->update_func = scm_make_gsubr (@dots{});
> 
> 
> So I think nothing would stop the compiler from doing this:
> 
>    image->name = scm_string_copy (name);
>    image->update_func = scm_make_gsubr (@dots{});
> 
>    { if ((6 & (int)( scm_freelist )) )  image_smob  = scm_gc_for_newcell();	else {  image_smob  = scm_freelist; scm_freelist = (((scm_cell *)((  scm_freelist  ) ))->cdr) ;	++scm_cells_allocated; } } ;
>    ((((scm_cell *)((   image_smob   ) ))->cdr)  = (SCM)(  image )) ;
>    ((((scm_cell *)((   image_smob   ) ))->car)  = (SCM)(  image_tag )) ;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]