[M3devel] returning record by value vs. by ref?

[Jay]

1) Can pinning not be exposed reasonably in the language?
I'll keep my pointer just a short time, in a local.
 
2) surely it could be done at an outer layer?
Make volatile locals for things you don't want enregistered?
 
Even the accessor function approach seems lame, given that I believe the Win32/x86 compiler doesn't inline.. :(
(does the gcc m3 inline across modules, or just compiles one at a time?)
 - Jay



> CC: jay.krell at cornell.edu; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] returning record by value vs. by ref?> Date: Sat, 1 Dec 2007 15:23:19 -0500> To: rodney.bates at wichita.edu> > Correct! Anytime you create an l-value pointer.> > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > Tony Hosking wrote:> >> I am assuming 's' here is an open array (REF ARRAY OF item) in > >> which case it is allocated in the GC'd heap. There is certainly > >> no way of safely getting an interior pointer to items in the > >> stack in Modula-3 -- at least not one that you can upward expose > >> (to callers) via return from a procedure. The difficulty in > >> doing this is that the GC moves objects around and would need to > >> know where your manufactured interior pointer is being held and > >> to which *object* (ie, the open array in this case) it refers so > >> that it can 'fix' the pointer when the array object moves. > >> Modula-3 provides a small concession to obtaining downward > >> exposed interior pointers using the VAR parameter mode. For > >> example you can pass 's[i]' as an actual parameter to a VAR mode > >> formal, effectively passing a pointer to the callee. GC can cope > >> with this in one of two possible ways: 1) "Pin" the array so that > >> it cannot be moved while the interior pointer is held on the > >> stack or registers of any thread (this is the approach that CM3's > >> conservative collector uses for now); or 2) track the creation of > >> such interior pointers and how they are derived from base object > >> references for use during GC. 2) requires much more co-operation > >> from the compiler than the current gcc-based backend (with all of > >> its lovely optimizations and register allocation) is capable of > >> doing. 1) is very cheap and does not impede optimizations and > >> register allocation.> >> > Presumably, this all also applies WITH-bound identifiers, when they > > are> > designators of interior components of heap objects? Are there any > > other> > cases?> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> 
_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.  Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071201/18b5bb72/attachment-0002.html>