Dynamically choosing a register

[J J]

> Date: Tue, 24 Jul 2007 20:37:12 +0300> From: siguctua at gmail.com> To: exupery at lists.squeakfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/exupery/attachments/20070725/4423b94c/attachment.htm