Re: Data Structure Reorganizing Optimizations

leichter@zodiac.rutgers.edu writes...
>I agree absolutely that the rules are obsolete. In fact, they were obsolete
>the day they were written.
>
>The real underlying problem is that a struct can be interpreted in two
>different ways:
>
> 1. As an abstract data type, . . .


> 2. As a way of laying out data in a particular pattern in memory.
> Obviously, re-organization kills this.


          Amen! Somebody hit the nail on the head!


          Does anyone know of any languages that handle this well? I'd love
to read about 'em.


          Foreign structure/call interfaces in some Lisps do a careful job
of defining layout, calling and argument passing details - but I don't
know of any standards in the area.


          Does anybody know of better examples? How 'bout ANDF's interface
definitions? I've got the paper somewhere, haven't read it in detail
yet, will hafta dig it up. What about various RPC ISLs?


          Stack frame, device register, network message layout, etc. are all
interface issues. The interface description oughta be clearly separated
from (but related to) the ADT description. When there is no external
interface, the compiler should be free to reorganize. When separate
compilation of related modules within a single program is an issue,
programming environments would need to be improved to deal with the
possibility of reorganization.
--

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