Squeak-dev March 2000

squeak-dev@lists.squeakfoundation.org

131 participants
580 discussions

Re: [Q] executing SOME compiledMethod (classless)
by Bob Arning 31 Mar '00

31 Mar '00

On Fri, 31 Mar 2000 15:28:05 +0200 "Peter Novak" <pno(a)whitestein.com> wrote: >I need to execute some compiled method which doesn't belong to ANY class. We >need something like executing SOME byteCode without having it installed in >any class. Peter, It's not really clear what you want here. One question is: who would be the receiver of the method context (i.e. to what object would <self> refer in your method)? If you have a receiver, then the receiver *will* have a class. If you don't have a receiver, then I imagine things would break all over the place. Perhaps you could explain a little more about why you don't want it to belong to ANY class. If you don't want to add the method to an existing class, what about creating a class just for this purpose and deleting it afterwards? Cheers, Bob

1 0

Re: [BUG][FIX][UNIX] VM bugs and make problems
by Michael Rueger 31 Mar '00

31 Mar '00

Michael Rueger wrote: > after applying the changes Bert (thanks!) sent for the parameter > problems I had some more... > Problems and changes that is ;-) > > 1) The command line arguments were off by one (the image name was passed > in twice) and the last argument was ignored. Oops, somehow I mixed up stuff in Davids code with Berts sources... I think what I fixed was Davids code. Where's the C-code changeset browser in Squeak? ;-) 8-| Michael

2 1

Re: [BUG][FIX][UNIX] VM bugs and make problems
by Bert Freudenberg 31 Mar '00

31 Mar '00

On Thu, 30 Mar 2000, Michael Rueger wrote: > 2) The target headless in the make file is missing You have to run "../conf/configure --without-x" manually from the build directory ... But you're right, that's not obvious, and there are some minor (known) bugs - like HEADLESS not getting defined with certain autoconf versions. A workaround is to put this on top of sqXWindow.c: #ifndef HAVE_LIBX11 #define HEADLESS #endif > Andreas hacked a workaround, but maybe one of the countless ;-) > config/make wizards can fix this? You could automate this by inserting the following in the toplevel Makefile: reconfigheadless@: @$(MAKE) CONFARGS=--without-x reconfig @-/bin/rm -f $(TARGET)/sqXWindow.o Then you just have to type "make reconfigheadless squeak" to build a headless vm. -Bert-

1 0

Re: FFI for MacOS-X-Server
by Marcel Weiher 31 Mar '00

31 Mar '00

> From: Henrik Gedenryd <Henrik.Gedenryd(a)lucs.lu.se> > > you should definitely check my FFI fixes change set (on the FreeType page), > once you start using FFI inside Squeak. Thanks, I'll check them out. > I haven't had all the changes > cleared by Andreas, and they are based on my guesses about how FFI is > supposed to work, but some of the issues confused me a great deal. Among > other things one bug led me to believe that declarations worked quite > differently than they really do. Yes, things are definitely not very clear yet, at least to me. > Good luck, Marcel. BTW, does SqC know that you are in effect doing their > work for free in developing the next version of the Mac VM? Who knows...I just hope they figure out quickly what an amazing platform for OO MacOS-X is. Many of the things that are starting to be handled in a sort of ad-hoc fashion have pretty polished implementations in X. Portability must be preserved, of course, but it wouldn't hurt to base such mechanism on a model that has been refined over 10 years (and where the creators weren't sissy in sacrificing backwards compatibility). Having the semantic gap between Squeak and its substrate minimized also clears up quite a bit. Marcel

1 0

Re: FFI for MacOS-X-Server
by Henrik Gedenryd 31 Mar '00

31 Mar '00

Marcel, you should definitely check my FFI fixes change set (on the FreeType page), once you start using FFI inside Squeak. I haven't had all the changes cleared by Andreas, and they are based on my guesses about how FFI is supposed to work, but some of the issues confused me a great deal. Among other things one bug led me to believe that declarations worked quite differently than they really do. Good luck, Marcel. BTW, does SqC know that you are in effect doing their work for free in developing the next version of the Mac VM? Henrik

1 0

RE: FFI for MacOS-X-Server
by Raab, Andreas 31 Mar '00

31 Mar '00

Marcel, The use of 'addr' as indirect pointer is due to a pretty stupid definition in the MacOS (pre X) runtime architecture. The code fragment architecture exports an entry vector consisting of the actual function address (the indirection you see) and the frame base for the function you're calling, rather than adding a bit of glue code for each function that loads the frame pointer when the fragment is entered. Since the caller has to load the frame pointer before entering a fragment this leads to the situation that the C compiler generates (for each function call through a pointer) a call that actually goes to the infamous .ptr_glue which is basically what you see in the FFI code.[Note: the really, REALLY stupid thing is that this requires the C compiler to call .ptr_glue even in cases where the call does not go cross-fragment. You can probably imagine what that means for, e.g., a primitive dispatch table, or a table of combination rules]. I do not know if this has changed with MacOS X (I sure hope so). You will need to dig deep down in the documentation for this (I have no info whatsoever on this issue) to find out. The best way I can think of is to check the assembly code that GCC generates for a function call through a pointer, e.g., for something like: int testFunc(int addr) { return ((int (*) (void)fn)(); } - Andreas > -----Original Message----- > From: Marcel Weiher [mailto:marcel@metaobject.com] > Sent: Thursday, March 30, 2000 2:15 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: FFI for MacOS-X-Server > > > Hi folks, > > I am currently working on getting FFI up and running on > MacOS-X-Server. > > As the assembly calling conventions are AFAIK the same as for MacOS > (having been taken from AIX), I used Andreas's Mac code as a > starting > point. However, the gcc inline assembly mechanism is not identical > to the one used there, so I've had to adapt the function > ffiCallAddressOf(). > > It's mostly working now, but there are some points of the code I am > unclear about, mostly the commented out parts where the > original code > treated the 'addr' argument as an indirect pointer. Is this > correct? On my machine, the address that gets passed here is the > direct address of the functin in question (which is why it works no > that I've commented out the indirection). There is some code > related > to this that I've also removed, primarily dealing with GPR2 (frame > pointer?) and putting other stuff relative to the "indirect address" > argument. > > Can anyone shed light on this? > > Thanks, > > Marcel > > ---------- ffiCallAddressOf() as modified for > gcc/MacOS-X-Server ------ > > int ffiCallAddressOf(int addr) > { > int stackBytes = ffiStackIndex*4; > int stackGrowth = stackBytes+24; > void **destination; > int i; > printf("addr= %d %x\n",addr,addr); > stackGrowth=-stackGrowth; > > /* adjust stack frame */ > asm( "stwux r1, r1, %0" : : "r" (stackGrowth) ); > /* load the stack frame area */ > > asm( "addi %0, r1, 24 " : "=r" (destination) : ); /* dst > = SP + linkage area */ > for (i=0;i<ffiStackIndex;i++ ) { > destination[i]=ffiStack[i]; > } > > if ( fpRegCount > 0 ) { > if ( fpRegCount > 8 ) { > asm( "lfd f8, %0" : : "" (FPRegs[7])); > asm( "lfd f9, %0" : : "" (FPRegs[8])); > asm( "lfd f10, %0" : : "" (FPRegs[9])); > asm( "lfd f12, %0" : : "" (FPRegs[10])); > asm( "lfd f12, %0" : : "" (FPRegs[11])); > asm( "lfd f13, %0" : : "" (FPRegs[12])); > } > asm( "lfd f1, %0" : : "" (FPRegs[0])); > asm( "lfd f2, %0" : : "" (FPRegs[1])); > asm( "lfd f3, %0" : : "" (FPRegs[2])); > asm( "lfd f4, %0" : : "" (FPRegs[3])); > asm( "lfd f5, %0" : : "" (FPRegs[4])); > asm( "lfd f6, %0" : : "" (FPRegs[5])); > asm( "lfd f7, %0" : : "" (FPRegs[6])); > } > if ( gpRegCount > 0 ) { > if ( gpRegCount > 4 ) { > asm( "lwz r7, %0" : : "" (GPRegs[4])); > asm( "lwz r8, %0" : : "" (GPRegs[5])); > asm( "lwz r9, %0" : : "" (GPRegs[6])); > asm( "lwz r10, %0" : : "" (GPRegs[7])); > } > asm( "lwz r3, %0" : : "" (GPRegs[0])); > asm( "lwz r4, %0" : : "" (GPRegs[1])); > asm( "lwz r5, %0" : : "" (GPRegs[2])); > asm( "lwz r6, %0" : : "" (GPRegs[3])); > } > /* go calling out */ > asm( "mr r12, %0 " : : "r" (addr) ); /* tvector > into GPR12 */ > /* Note: The code below is nearly identical to to what's > described in > "MacOS Runtime Architectures" > Chapter 2, Listing 2-2, pp. 2-11 > */ > // asm( "lwz r0, 0(r12) "); /* get entry point */ ?? > // asm( "stw r2, 20(r1) "); /* save GPR2 */ ?? > asm( "mtctr r12 "); /* move entry point into count > register */ > // asm( "lwz r2, 4(r12) "); /* new base pointer */ > asm( "bctrl "); /* jump through count register and > link */ > // asm( "lwz r2, 20(r1)" ); /* restore GPR2 */ > asm( "lwz r1, 0(r1)" ); /* restore frame */ > > /* store the result of the call */ > asm( "stw r3,%0" : "=g" (intReturnValue) : ); > asm( "lwz r12,%0" : : "" (longReturnValue) ); > // asm( "stw r3, 0(r12)"); > // asm( "stw r4, 4(r12)"); > asm( "stfd f1,%0" : "=g" (floatReturnValue) : ); > > } >

1 0

Re: VM Query: Contexts on Stack?
by Alan Kay 31 Mar '00

31 Mar '00

Les -- Again, for completeness, we should include Ben Dent and Glen Oliver. But Bob Barton was the "genius"... By the way, Ted Glaser was a concert pianist and blind from the age of 12. He was also one of the main designers of the DEC 340 display and was Ron Baecker's thesis advisor of GENESYS, the first thesis on computer controlled frame animation (1969)! Cheers, Alan --------- At 4:37 AM -0800 3/30/00, Les Tyrrell wrote: >Alan Kay wrote: >> >> And ... >> >> I should mention that the origin of the bytecode interpreters was the >> hardware of the Burroughs B5000, first described in print in 1961. I used >> this as a model for the Flex machine in the late sixties, including the >> idea of overlapping contexts (it's a direct consequence of one way to have >> the compiler map the stack). The B5000 also had HW flag bits to distinguish >> its typed pointers from data, the ability to call procedures on the left >> side of an assignment statement (so many kinds of data could be simulated), >> automatic HW process switching, addressless bytecodes, segmented swappable >> memory structures, etc. It was designed by one of the great geniuses of our >> field (and unfortunately not remembered today), Bob Barton. >> >> Cheers, >> >> Alan > >Just for kicks- I recalled reading about this in Ted Nelson's Computer Lib, >which I just happen to have handy. In the edition I have, on pages 40&41 >he has the subject "Some Great Computers". But when you turn the page, at the >top left of page 42 he has "The Very Great 5000" - a description of the >Burroughs >machine, in a category of its own. > >He also mentions the designers as being Bob Barton and Edward Glaser. > >So, much belated but quite sincere- "Way to go guys!!!" > >-les

1 0

Re: [2.8alpha][GOODIE][FIX] Client Server Framework (very basic)
by Benoit St-Jean 31 Mar '00

31 Mar '00

"Richard A. O'Keefe" wrote: > Well, actually, if you check the following > http://machaut.uchicago.edu/cgi-bin/WEBSTER.sh?WORD=rendezvous > you'll find that (in 1913, at least) the plural of "rendezvous" was actually > "rendezvouses", although it was considered rare even then. Just goes to > show how languages evolve. "rendez-vous" is actually a verb in french and also an expression which is called a "locution" in french. It is "invariable" which means that the plural form as well as the singular form are the same. The verb is "rendre" at the 2nd person of the plural which is "rendez". The "vous" part is the 2nd person of the plural which is equivalent to the you pronoun (plural). The verbe tense is what we call "impératif" in french which is used to denote an order. We could translate the verb "rendez-vous" in english in "Rendez-vous au stade olympique à 3 heures" by "Be at the Olympic Stadium at 3 o'clock". Technically though, "rendre" means "go to". Technically, just as we do in french, you should use the "original" spelling of the noun or verb just as we do with foreign words (such as latin) and not accord it OR accord it the way it should have been in it's "native" form. For instance, the plural of "maximum" (a latin word) is "maxima" (in latin) and not maximums as it "should" have been according to french rules... Hope this helps... An ex French litterature teacher now converted to Smalltalk programming speaking here... P.S. Sorry for my poor written English...

1 0

London Squeak Group anyone?
by Tom Ayerst 30 Mar '00

30 Mar '00

Hi All, Is there a group of squeakers in London? If there isn't would anyone be interested in forming one. I'm based in near Heathrow and work in the City so anyway between them would be okay. What I had was a weekly get together to do some coding and exploration. I work best collaboratively and I think it would be fun. Anyone interested? Rgds. Tom

1 0

Re: VM Query: Contexts on Stack?
by Allen Wirfs-Brock 30 Mar '00

30 Mar '00

At 07:34 PM 3/29/00 -0800, Dan Ingalls wrote: >... >If we are talking about putting contexts in the hardware stack, I did this >half a decade earlier. Smalltalk-78 ran on a 4MHz 8086(*). The VM was 6K >of code. And it put its contexts right in the hardware stack. I also used >the trick of overlapping adjacent contexts so there was no need to transfer >arguments (Ian and I have been discussing doing this for Squeak -- it >requires pushing the receiver last instead of first). >... Pat Caudill and I did something similar in Tektronix Smalltalk but did not have to change the push order. Probably the most interesting aspect of this implementation was that we used two stacks to cache the active contexts. One stack (the "object stack")contained the args/temps/evaluation-stack and the other stack (the "control stack") contains the control data (IP, method pointer, home pointer, etc.). The object stack used overlapping stack frames and only contained oops. The control stack only contained machine addresses. Object stack frames are variable sized, control stack frames are fixed size. The control stack state was design such that it could address into either the object stack or into a heap allocated context object in a manner that was transparent to the bytecode implementations. Thus there was no need to re-cache a context if it had been flushed to the heap. The use of the two stacks eliminates almost all of the complexity of "parsing the stack" by the GC or when reifying the stack. In general we have been very happy with the two stack model. Subsequent to the Tektronix implementation we have used it with success in all of our VM designs as well as a Java runtime environment that we designed. Much of the complexity of context caching schemes arises because in the most general case a Smalltalk-80 context aggregates into a single object entities with inherently different lifetime extents. Some entities("the activation record") have LIFO extents others ("block objects", variables referenced from blocks, etc.) have indefinite ("heap") extents. Things get much simpler if the architecture explicitly separates the entities with different life cycles into separate objects. For example, the Smalltalk compiler can easily identify which local variables are solely referenced from within a single activation and which are "captured" by a block with indefinite extent. With this knowledge it is possible to place the captured variables in a heap allocated "environment" object while placing all other local variables in a stack allocated activation record. Different bytecodes are then used to distinguish between accesses to "stack" or "heap" allocated variables. All of the Digitalk Smalltalk virtual machines used architecturally explicit stacks in this manner. One of last of these designs is documented at: http://www.smalltalksystems.com/publications/avmarch.pdf. Allen_Wirfs-Brock(a)instantiations.com

1 0

Jump to page: