After thinking more about this, I think we should add another enumeration type to vpiAllocScheme: vpiNoneYetScheme - or - vpiInactiveScheme - or - vpiUnboundScheme - or - vpiNoActiveScheme - or simply - vpiNoScheme My reasoning is that if we want to principally reflect "scheme"s of *active* objects, ... 1) vpiStaticScheme objects will *never* have the above scheme value (they will *always* get vpiStaticScheme, correct ?); 2) automatic objects, when inactive, can be distinguished from would-be dynamic objects by the existing vpiAutomatic property (which should be made available in for all objects it could relate to); 3) We can defer resolution of the specifics of what this new "non alloc" scheme means (the shades of gray) with a separate property (or additional enumerations) later. 4) I think it's OK if we codify that there are no VC CB's allowed on these *ever* (they can never *attain* a value), and that they can *never* be subject to "upgrades" to active handle versions, i.e. the handle must be reacquired. 5) No handle "tracking" CB's are required (or allowed) for this "non scheme" type. Down the road, we may want to think about a property that reflects "Object Binding Level" or "Integrity Level" (or another incarnation of Handle Aspects, as Abi had proposed). My 2 cents, Chuck ________________________________ From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of John Shields Sent: Thursday, March 20, 2008 2:26 PM To: Jim Vellenga Cc: sv-cc@eda.org Subject: [sv-cc] Re: Mantis item 2226: Memory allocation schemes Hi Jim, We had a good discussion about this today, as you know, though not all your points. One big bucket result is that we recognize that this proposal was aimed at the post elaboration information model. As such, the focus was on objects that have been instantiated and have value. They may be static or transient objects with limited lifetimes. We agreed that there is a need to unify this with the "src code" information model. (That might also come to be known as the uninstantiated or post-analysis information model.) We recognized that it is impractical to analyze this thoroughly in the time remaining. The goal we set was to attempt to identify a minimal answer to the same questions: How do we classify the memory allocation scheme for a src object? vpiAllocScheme property either isn't available or has a value for these objects and we have to decide that. What does the vpiAutomatic property mean for "src code" objects? Same considerations as above. Beyond that, we might aspire to distinguish other aspects of src code objects. The problem is that "pulling on that string" may unravel for a while. To decide what properties give us adequate information about a src code object implies you appreciate when you get one, what you can do with it, and how it interacts with the runtime. Getting a src code object that is an expression, yet saying that the object will produce a value in a runtime context begs a lot of shared understanding. Is it really the same object or did you just navigate to it the same way at a different point in time and get 2 different objects? If you can evaluate it for a value, what are the properties of the vpi evaluator? How safe must it be? Note, I am only demonstrating pulling on the string, not expressing or implying anything I believe about this. We agreed that a principle for getting closure for this round of the LRM was that we may remain silent about some aspects, rather than make a step in a controversial direction in a hasty manner. The spec remains worse than a work in progress and we gain time and experience with the new revised information model. Regards, John (further comments below) Jim Vellenga wrote: John and all, I can see some merit in the proposed vpiAllocScheme property. It seems that we are using it to define the default allocation scheme for scopes and actual allocation scheme for objects. Is that correct? If so, some thoughts: -- Would it be good to tie it in explicitly to the new proposed section "36.3.6 Lifetimes of objects"? One could even define the new property here and cross reference it from the details, rather than cross referencing the various details to the fairly sketchy detail in the section on variables. Yes it would. I did not want to re-organize the information initially. Keeps the principle of least astonishment for the reviewer. I kept the change aligned to where we have the property vpiAutomatic today, so we could review as a extension of that concept. It is much better to describe it once and refer to it. I'd prefer it. -- The proposed 36.9 detail 9 needs to be rewritten. I don't think we really mean that vpiAllocScheme indicates how the instance itself is allocated in memory, do we? Correct. This was a bit hasty of a cut and paste. I meant it to indicate how the objects within an instance, by default, would be allocated. In retrospect, it is unecessary at the level of the instance to do so. The fact is, vpiAutomatic and the type of the instance directly answers the question without requiring navigation to some other object. -- I see that we've never put the vpiAutomatic property on tasks or functions in the first place, even though, with SystemVerilog, then can have an automatic or static default scope. Should we add vpiAutomatic? Should we add vpiAllocScheme? After our discussion, I want to think about it. My gut is that vpiAutomatic should be there and have the same meaning as it has for an instance. vpiAllocScheme is probably not that useful. The central writeup of these properties will help unify it and answer the question. I'll get back to you. -- Things get more ambiguous, of course, with a task or function (method) declared in a class. Consider the following, for example: module top; class C; static function automatic int f (int x); return -x; endfunction endclass endmodule Notice that the method 'f' has a static lifetime but an automatic default lifetime for its variables. Should we use vpiAutomatic for the method's default variable lifetime, and reserve vpiAllocScheme for the function's own lifetime? No, I don't think so right now. vpiAutomatic should reflect the default for locals of the function as it does for an instance. The other aspect of the function, in my mind, is a new property that we do not need with any high priority. I think it would require a different tag. I will think about it a bit more. -- If an automatic variable is obtained from a function declaration (syntactically) it really has a lifetime that is independent of simulation, even though it has been declared with the keyword 'automatic'. But if we obtain the corresponding variable from a frame, then the vpiAllocScheme is unambiguously vpiAutomaticScheme. What should the vpiAllocScheme be for the variable obtained from the syntactic context? Given my comments at the top of the email, I am leaning toward a new enumerated value, vpiUninstantiatedScheme. I know it is a long name, but it is precise enough. If we wanted short, vpiSrcScheme would be a possibility. BTW, it is tempting to say, from a purely orthoganal perspective that the existing vpiStaticScheme is adequate, if you know that the object is a src code object. That leads us to "pull on the string" again. I expect we need to know in the information model that really unifies the "src code" view, but we could only be silent about it for now. If so, it is cleaner to define a new enumerated value. What do you think? Regards, Jim Vellenga --------------------------------------------------------- James H. Vellenga 978-262-6381 Software Architect (FAX) 978-262-6636 Cadence Design Systems, Inc. vellenga@cadence.com 270 Billerica Rd Chelmsford, MA 01824-4179 "We all work with partial information." ---------------------------------------------------------- ________________________________ From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Shields, John Sent: Wednesday, March 19, 2008 10:20 PM To: sv-cc@eda.org Subject: [sv-cc] updated mantis item 2226 with proposal Hi, This is detailed proposal of the information model for dynamic objects. There are changes to clause 36 and 37 in 2 documents. Regards, John Shields Mentor Graphics, Inc. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 20 14:57:56 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 20 2008 - 14:58:15 PDT