Squeak-dev December 1999

squeak-dev@lists.squeakfoundation.org

146 participants
451 discussions

Re: CompiledMethod>>value:withArguments:
by Ian Piumarta 29 Dec '99

29 Dec '99

> Method wrappers are an extremely useful technique to gather all > kinds of run-time information, to implement wrappers, ... [...] > It seems to me that Squeak is missing in reflective facilities in message > handling. Sounds to me like a challenge. ;^) > For that matter, so are most Smalltalk VM's. Ahh, but the beauty of Smalltalk is the possibility of reifying and interceding on all execution state: if it's missing then you just go implement it, whatever "it" might be. (And if it doesn't run blindingly fast afterwards then consider it a bug in the VM's runtime. ;-) > > Don't you think we could solve this by doing something along the lines of: > > CompiledMethod>>valueWithReceiver: aClass Arguments: argList > > | aProcess aContext | > > aContext _ MethodContext > > sender: thisContext sender > > receiver: aClass > > method: self > > arguments: argList. > > aProcess _ Process forContext: aContext priority: Processor activePriority. > > aProcess resume Process? Isn't this a bit like swatting a fly with a steam roller? Methinks the problem is a little more subtle. For starters, a minimum of verification for compatibility between the CompiledMethod and the given receiver/arguments is required. (We've come a long way since "Processor := nil" for cruel and unusual ways in which to crash the VM. ;-). Try the following instead... Behavior methodsFor: 'testing method dictionary' includesMethod: aCompiledMethod "Answer whether aCompiledMethod is in the method dictionary of the receiver." ^self methodDict includes: aCompiledMethod canExecute: method "Answer whether the receiver implements a message whose method is the argument. The method can be in the method dictionary of the receiver or any of its superclasses." (self includesMethod: method) ifTrue: [^true]. superclass == nil ifTrue: [^false]. ^superclass canExecute: method CompiledMethod methodsFor: 'evaluating' valueWithReceiver: anObject arguments: argumentArray "Answer the result of executing the receiver with anObject as receiver and argumentArray as arguments. Signal an error if the receiver is not a method suitable for anObject, or if the argumentArray contains the wrong number of arguments for the receiver." (self numArgs == argumentArray size and: [anObject class canExecute: self]) ifTrue: [thisContext swapSender: (MethodContext sender: thisContext sender receiver: anObject method: self arguments: argumentArray)] ifFalse: [self error: 'receiver and/or arguments not appropriate for this method'] Examples: (SmallInteger compiledMethodAt: #+) valueWithReceiver: 3 arguments: #(4). (Number compiledMethodAt: #//) valueWithReceiver: 22 arguments: #(7). (SmallInteger compiledMethodAt: #+) valueWithReceiver: 3 arguments: #(foo). (Number compiledMethodAt: #negated) valueWithReceiver: 22 arguments: #(). (Number compiledMethodAt: #negated) valueWithReceiver: 22 arguments: #(7). (Point compiledMethodAt: #=) valueWithReceiver: 3@4 arguments: #(4). (Point compiledMethodAt: #=) valueWithReceiver: 3 arguments: (Array with: 3@4). And finally (for the incurably skeptical): (CompiledMethod compiledMethodAt: #valueWithReceiver:arguments:) valueWithReceiver: (SmallInteger compiledMethodAt: #+) arguments: #(3 (4)) FWIW: The only part of the above implementation that isn't blindingly fast is the inclusion test for the method somewhere in or above anObject class. (The corresponding primitive [twenty lines of code, tops] could do the test iteratively, and would be about the same speed as #perform:. Left as an exercise for anybody who still has a mains electricity supply after midnight on the 31st...) Happy wrapping! Ian PS: > In VW this is a primitive I suspect that the primitive response in VW is nothing more than a "hook" that the runtime uses to recompile the send site into something entirely more intelligent that (ab)uses the inline cache and/or method prologue for #valWithRcvr:args: to make the response as fast as a normal message send. (Otherwise the [slower] 100%-Smalltalk implementation is entirely sufficient.)

2 2

RE: [Q] constant class pointers?
by Raab, Andreas 29 Dec '99

29 Dec '99

Andrew, > (I always wondered why the interpreterProxy doesn't provide > direct access to the special objects array, which would be > another useful place to safely store remappable information. This would be an extremely bad place to store arbitrary information about remappable OOPs. Mind you - the special objects array contains 'special' objects, not just any objects. If you store some pointer into slot X which is not used in 2.6 but *is* used in 2.7 then you'll just break the system. Andreas

1 0

RE: [Q] constant class pointers?
by agree＠carltonfields.com 28 Dec '99

28 Dec '99

> Remain class pointer of classes Integer, LargePositive/NegativeInteger > constant after recompiling these classes (for changing and adding some > methods)? It should. Oops are oops. A pointer to a class object, which pointer is residing in the Object memory model, will not be invalidated by changes to the content of that class object. > Need to know this for install instruction of a LargeIntegers > (arithmetics) plugin. Watch out! Oops are oops. A pointer to a class stored outside the Object memory model will NOT be updated during garbage collection. Accordingly, if you store it in a global between primitive calls, if you store it in a local during a primitive call with a call that can invoke GC, you must PRESUME the GC has invalidated the pointer! Accordingly, you must provide facilities to assure that the oop is remapped (either by reloading it from the parameter stack, or by popping it from a the remappable object stack). (I always wondered why the interpreterProxy doesn't provide direct access to the special objects array, which would be another useful place to safely store remappable information. In another posting, I proposed an unworkable solution of storing an oop in a global during a class initialization (which chokes on the likely GC between primitive calls). If the oop could be stored in the special objects array, and the index thereto could be stored in the global, this functionality could be accomplished.)

1 0

RE: Organizing VM sources, CCodeGenerator: suggestionsandquestions
by Raab, Andreas 28 Dec '99

28 Dec '99

> So, help me out -- does the V2.6 VM interpeterProxy support > classLargeNegativeInteger() or not? It doesn't. The addition was in the 2.7alpha update stream. > If so, I'm confused why that code crashed earlier, > but worked when I passed the class as a parameter. (Maybe I > just ran that unit test wrong -- I'll get back to you). If > not, I'm confused why the plugins ran at all. That's quite strange - perhaps there is a bug in the support code somewhere... Andreas

1 0

Re: CompiledMethod>>value:withArguments:
by Ian Piumarta 28 Dec '99

28 Dec '99

> Thanks. I tried some of these (they seemed to work or failed when they > should), but > > (Point compiledMethodAt: #x) valueWithReceiver: 3@4 arguments: #() > > crashes on my machine (Squeak 2.6, Win98), followed by fatal error when > opening the debugger. It's a Compiler bug. The method Point>>x has a primitive response that never fails ("quick push of instance field") and since the Compiler expects the runtime to respond to this without ever trying to execute bytecodes, it doesn't bother generating any bytecodes in the method at all. To fix this, in Compiler>>generate: modify the final return in the block argument to the first send to simply record the primitive index for the quick response: self generateIfQuick: [:method | primitive _ method primitive]. then re-accept Point>>x and try the example again. [Dan: here's an example of cheating and then getting caught. ;-)] Ian

3 2

[Q] constant class pointers?
by Stephan Rudlof 28 Dec '99

28 Dec '99

Dear Squeakers! Remain class pointer of classes Integer, LargePositive/NegativeInteger constant after recompiling these classes (for changing and adding some methods)? Need to know this for install instruction of a LargeIntegers (arithmetics) plugin. Greetings, Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 1

[BUG] To many temps lead to crash or endless loop...
by Stephan Rudlof 28 Dec '99

28 Dec '99

Squeakers, I have written an adHoc - not nice - testing method, which evolved from workspace computation: 28 temps were OK, but with one dummy var more -> endless loop; with some more -> crash! I've searched a while for the reason of this problem, then I've systematically reduced the complexity of this method and came to these results. After that I've taken a look onto the Squeak-ML and found a limit of 31 or so... Does anybody know, if it is possible to avoid crashes and throw an exception or simply an error message? Sorry, I'm not a VM specialist... But I hate crashes! Greetings, Stephan P.S.: I don't want to start a discussion about sense or nonsense of so much temps: I've wanted to reduce them and will do so, but for quick testing by copy and paste it was comfortable, but then I was punished... -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 1

Re: CompiledMethod>>value:withArguments:
by Ian Piumarta 28 Dec '99

28 Dec '99

Oops... > To fix this, in Compiler>>generate: That should read: in MethodNode>>generate: Sorry. Ian

1 0

CompiledMethod>>value:withArguments:
by Stephane Ducasse 28 Dec '99

28 Dec '99

Hi I wanted to port the MethodWrappers of John Brant to Squeak to learn a bit more the differecne between VW and Squeak and I discovered that there is no way (or I did not find it) like in VW to execute a method. In VW we can invoke a method by sending it the message valueWithReceiver: arguments: . Is there any plans to introduce this in Squeak? In VW this is a primitive and it give a lot of power to build tracing, debugging....tools. See http://st-www.cs.uiuc.edu/users/brant/Applications/MethodWrappers.html. Stef Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

3 2

RE: [BUG][FIX] TestCodeGenerator
by agree＠carltonfields.com 28 Dec '99

28 Dec '99

This bug was fixed in a changeset published during the holidays. > -----Original Message----- > From: MIME :sr@evolgo.de > Sent: Tuesday, December 28, 1999 10:32 AM > To: squeak(a)cs.uiuc.edu; werdna(a)gate.net > Subject: [BUG][FIX] TestCodeGenerator > > > Dear Squeakers, > > attached change set removes a bug in TestCodeGenerator, which > occured if > calling > ^true asOop: Boolean > in a TestInterpreterPlugin method. > > Greetings, > > Stephan > > P.S.: In the original method there was also an in ST invisible > character, what was seen by the C compiler though and led to > a compiler > error. > > -- Stephan Rudlof (sr(a)evolgo.de) > "Genius doesn't work on an assembly line basis. > You can't simply say, 'Today I will be brilliant.'" > -- Kirk, "The Ultimate Computer", stardate 4731. > 'From Squeak2.7alpha of 1 December 1999 [latest update: > #1726] on 27 December 1999 at 5:38:18 pm'! > > !TestCodeGenerator methodsFor: 'asOop:/asValue:' stamp: 'sr > 12/27/1999 05:50'! > generateCoerceToBooleanObjectFrom: aNode on: aStream aStream > nextPutAll: '('. > self emitCExpression: aNode on: aStream. > aStream nextPutAll: '? interpreterProxy->trueObject() : > interpreterProxy->falseObject())'! ! > > > >

1 0

← Newer
1
2
3
4
5
6
7
8
...
46
Older →

Jump to page: