> Date: Tue, 24 Jul 2007 20:37:12 +0300> From: [EMAIL PROTECTED]> To:
> [email protected]> Subject: Re: Dynamically choosing a
> register> > as i understood, you want to do similar by telling a send oop,
> where> to store a result.> well, you may point to stack index, or point to
> address of memory with> given stack index.> but i'm unsure, is stack in
> squeak are subject for GC relocations. if> so, then better use index rather
> than pointers.Ok, I sent this mail in a rush because I didn't want to still
> be on the train when it left my station, so I figured it wouldn't end up
> making sense. :)What I mean is, right now MethodConext's have various fields
> in them (BlockContexts as well, but they point to MethodContexts for most
> information). What I was thinking of doing was adding an addition field
> "returnLocation". This way the compiler can simply ensure the value that is
> to be returned stores it's value to that area directly.Example (I means
> instance variable location, O means Object for the general purpose registers,
> S is a special and L is the literal frame):center ^ origin + corner / 2might
> be translated to:send2 #+ I1 I2 O1 ; Send the message #+ with the
> first instance slot as the receiver (first object) and the second instance
> slot as the argument. Store results in GP register O1send2 #/ O1 S(2) RET ;
> Send #/ with O1 as the receiver and the special number 2 as the argument.
> store the result into what ever place *our caller* expects it to be storedret
> ; Destroy this context and reactivate the
> previous oneSo note above that when the receiver in O1 receives the #/
> message the RET field in *his* activation context will be the same as *ours
> (i.e. center's)*. So when he stores the answer we don't have to do anything,
> as it is in the right place already.The complexity comes from the fact that
> RET might be an instance variable, a temp variable location, a GP register
> *or* it may be an actual hardware register. But I'm not sure if that's even
> doable without making self-modifying code, which lead to my question: Can I
> have some value that I pass around dynamically that "points" to a hardware
> register?I can easily have a special encoding that says "the 3rd general
> purpose hardware register" or even the literal x86 value that maps to e.g.
> "eax", but how would one use this value at runtime? C, et al don't have this
> problem because the compiler explicitly states what values are going into
> which registers at build time. I have never heard of passing around a
> register "address".Of course I could do something like (note: the following
> pseudo code is intended to be a low level lisp-like language that compiles
> directly to machine code):(def store-to-register (reg val) (cond (reg)
> ((number-that-means-eax) (store eax val) .....But if it's going to be the
> expensive I may as well just store into memory. I was hoping I could do
> something like (example in pseudo assembly this time):movRegAt %ebx, $val ;
> the ebx register somehow has a reference to another register and stores $val
> there instead of ebx or memory or anywhere else.I suppose, since I have to
> have different functions for each addressing mode anyway, I can just have the
> routine that detects the type overwrite the register in the register store
> routine directly every time. :)Hopefully that makes a little more sense.
> :)Thanks,Jason
_________________________________________________________________
Don't get caught with egg on your face. Play Chicktionary!
http://club.live.com/chicktionary.aspx?icid=chick_wlmailtextlink
_______________________________________________
Exupery mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
