Self-interest September 1999

self-interest@lists.selflanguage.org

14 participants
14 discussions

Re: Grammar changes - comments?
by Randall.Smith＠Eng.Sun.COM 17 Nov '99

17 Nov '99

I must also say that even after programming in Smalltalk for years, I never missed not having cascades in Self. Maybe they just don't happen that often? At any rate, though they are a (possibly rare) convenience, having cascades would further distance Self from the Java/C programmer. (I have become of the opinion that some sort of pretty obvious syntax is almost a necessity for a language's acceptance. Java passed this hurdle by essentially re-using C/C++ syntax.) --Randy > From self-interest-return-287-Randall.Smith=Eng.Sun.COM(a)returns.egroups.com Mon Aug 30 12:47 PDT 1999 > Mailing-List: contact self-interest-owner(a)egroups.com > X-Mailing-List: self-interest(a)egroups.com > X-URL: http://www.egroups.com/list/self-interest/ > Delivered-To: listsaver-egroups-self-interest(a)egroups.com > Date: Mon, 30 Aug 1999 16:45:17 -0300 > From: Jecel Assumpcao Jr <jecel(a)lsi.usp.br> > MIME-Version: 1.0 > To: self-interest(a)egroups.com > Subject: [self-interest] Re: Grammar changes - comments? > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Using the "." for resends was a very unfortunate decision, and > your idea to replace it with "$" is a good one. I had suggested > using "::" since several other languages already use that for > similar purposes and Java (and Beta, in a negative way) showed > how important it is to have familiar elements in the syntax. > > About the cascades, you would need a "dup" bytecode (but since > you already were going to add it anyway this is no big deal). > I have never missed it when programming in Self, however. > > -- Jecel > > ------------------------------------------------------------------------ > Get help getting gigs! Guru.com will make your freelance work more > lucrative and more fun. Join us as we create the Internet's best resource > for independent professionals. http://clickhere.egroups.com/click/804 > > > eGroups.com home: http://www.egroups.com/group/self-interest > http://www.egroups.com - Simplifying group communications > > > > >

9 11

hardware implementation of PICs [long]
by Jecel Assumpcao Jr 06 Oct '99

06 Oct '99

Since this is a hardware issue, I am sending this to the Merlin list. Since this is a Self implementation issue, I am also sending this to the Self-interest list and apologize to anyone who receives two copies as a result. I will have to give some background to explain my idea, so this will be rather long. Those not interested in very low level implementation details will probably want to simply skip this entirely. Stefan Matthias Aust was asking about caching message lookups and we got into a discussion about Polymorphic Inline Caches (PICs). These PICs are simply short sequences of code that test the receiver's type (class in Smalltalk, map in Self) against a short list of candidates and jumps to the corresponding native code directly. If none of the alternatives are the correct one, then the traditional lookup system is invoked and it can extend the PIC so the current answer is found the next time around. To make this expansion easier, we might store the PIC in a separate memory region from the main code in the method and have that main code include a call to the PIC (by using jump instructions in the PIC, we guarantee that the return instruction in the invoked native method will bring us directly back to the main code). Since the number of entries in a PIC is small, the best implementation is something like: if (receiver->map == SmallIntegerMap) goto SmallIntegerAdd; if (receiver->map == FloatMap) goto FloatAdd; goto Lookup(receiver->map,"+"); The Self compiler can use this as a source of type information instead of (or together with) type analysis. It can tell that sending "+" to the object known as "receiver" at this point in the source code (known as the call site) has only resulted in either executing SmallIntegerAdd or FloatAdd. We can't know if there will be additional types for receiver in the future (though type analysis might be able to tell us that) so we won't be able to eliminate these tests from the compiled code (I am supposing we have decided to recompile this for some reason), but we can move them around and maybe merge them with similar tests nearby. Here is data presented in Table A-1 in Urs's PhD thesis: number of receiver types percentage of call sites 0 12.4% 1 81.9% 2 4.4% 3 0.8% 4 0.2% 5-10 0.2% 11-99 0.05% >99 0.02% Ok, so on to Merlin 6. This machine has 64K words of 80 bits each for use as a direct mapped data and "microcode" cache - 64 bits of data and 16 bits for the tags. The machine language in Merlin 6 is Self bytecodes: nothing else exists in main memory. When it needs to execute some bytecodes, the instruction pointer is extended with a special "context register" and the result is looked up in the cache. If the cache hits, then the data found there is microcode to be directly executed and *not* the bytecodes pointed to by the instruction pointer! This is a subtle, but very important difference relative to all architectures I am aware of. If the cache misses, then the CPU fetches microcode from a fixed location in a special region in the cache. This is the bytecode interpreter/compiler and it will fetch the bytecodes (storing them in the *data* region of the cache) and will either execute them directly or generate new microcode to be stored in the cache. The context register normally has a value of zero, but this can be changed by the microcode. This allows more than one microcode to be associated with a single bytecode. This is used not only to implement multicycle instructions (so it would be a microcode instruction pointer), but also for Self 4.0 customized compilation. About the microcode - the processor is a simple MOVE CPU (http://cardit.et.tudelft.nl/MOVE/) and each 64 bit word includes 4 move instructions that are executed in a single clock. I will represent one microcode word as [cond1]src1->dest1;[cond2]src2->dest2;[cond3]src3->dest2;[cond4]src4->dest4 which means that data in src1 is transfered to dest1 in this cycle if cond1 happens to be true. Since each word is in a cache, I will represent the whole thing as <IP,CR> microcode word This means that if the current value of the instruction pointer is IP and of the context register is CR, then this microcode word (the four moves) is executed. Here is an example of microcode for adding two integers: <109,0> [true] R2 -> ADDER_OP; [true] R3 -> ADDER_TRIG; ... ; ... <109,1> [true] ADDER_OUT -> R4 ; [true] INC_IP -> IP ; ... ; ... As you can see, this is even more primitive than a RISC CPU. But note that the compiler has complete control and could find interesting things to do with the four moves I have omitted from the example. When I was designing the Tachyon CPU, I came up with a nice implementation for PICs. But it used associative memory for the microcode cache and I can't put that in the Merlin 6. So here is the idea adapted for a direct mapped cache: <432,0> [true] R6 -> PIC_TRIG; [true] CONST32 -> PIC_OP; #???? <IntMap> [true] R0-> ADDER_OP; [true] R2 -> ADDER_TRIG; #7 -> CR; .. <FloatMap> [true] R0 -> FADD_OP; [true] R2 -> FADD_TRIG; #3 -> CR; .. <XXXXXX> ZZZZZZZZZ .... <432,3> [true] FADD_OUT -> R0; ... ; ... ; ... .... <432,7> [true] ADDER_OUT -> R0; ... ; ... ; ... I am supposing that by the time the CPU tries to execute the bytecode at memory address 432 (which would be "send '+'" or something similar) the map of the guy of the top of the stack has been loaded into R6. We move a 32 bit constant into the operation register of the PIC unit. This constant comes from the 32 lower bits in this cache word (shown as #???? above), so the last two moves don't exist (their condition is automatically forced to "false"). Meanwhile, R6 has been moved to the trigger register. The PIC unit compares bits 2 to 11 in R6 to three 10 bit values in the constant. Depending on which one matches, it fetches in the next clock the word in the cache located 1, 2 or 3 words after the one with these moves. Instead of comparing that word's tag with <IP,CR> as it normally does, it compares it with bits 12 to 27 in R6 and if they don't match it causes a cache miss. That constant would be calculated by the compiler like this: ???? = (((intMap >> 2) & 0x0FFC) << 20) | (((floatMap >> 2) & 0x0FFC) << 10) | 0; /* no third entry */ This way we can have PICs up to 3 entries (which is most of them) which start executing the destination code in just one clock. If the PIC has less than 3 entries (as in this example), the other cache lines can be reused for other things. This is a key feature of Merlin 6, so I would love to know of any flaws that I might have overlooked before I spend all my money on it. I am specially interested in the opinions of those who think that hardware of OO languages is a bad idea. -- Jecel

6 15

Re: OOPSLA
by Stefan Matthias Aust 21 Sep '99

21 Sep '99

At 14:42 20.09.99 -0700, Dru Nelson wrote: >I tried to get a show of hands for this a couple of months ago. >I think it would be a great thing. Who here is committed to going? Me, for 95% sure. It's a kind of expensive geek vacations for me ;-) bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

2 1

Self4Linux 0.1.0 Recompilation
by Otto Bommer 20 Sep '99

20 Sep '99

1. I tried to recompile Gordon Cichon´s Port of Self4 for Linux on my Suse Linux 2.2.5 system using GNU C++ 2.7.2.3. It compiled well the tools in self/bin/linux. When I tried to compile vm/linux/debug the compiler stops with the message below. The include and makefile mechanism used made it hard for me to track down where the origin of this error was. Does the message below make sense to someone of you and could somebody explane me the include and makefile mechanism used. I´d like to learn Self myself without having to buy a SparcStation myself. Otto Lake of Constance Germany ----------------------------------------------- Linking Self glueDefs.o: In function `._15::operator=(._15 const &)': /home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/prims/glueDefs.h:22: multiple definition of `._15::operator=(._15 const &)' i386-opc.o:/home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/asm/i386.h:25: first defined here glueDefs.o: In function `._15::._15(._15 const &)': /home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/prims/glueDefs.h:22: multiple definition of `._15::._15(._15 const &)' i386-opc.o:/home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/asm/i386.h:25: first defined here glueDefs.o: In function `._15::._15(void)': /home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/prims/glueDefs.h:22: multiple definition of `._15::._15(void)' i386-opc.o:/home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/asm/i386.h:25: first defined here abort.o: In function `fatalMenu(void)': /home/ootoo/Self/Self4Linux-0.1.0/vm/linux/debug/../../../vm/runtime/abort.c:226: the `gets' function is dangerous and should not be used. lock_run failed on "artist" with status = 1. -----------------------------------------

2 1

Book on Prototype-Based Programming
by James Noble 20 Sep '99

20 Sep '99

Hi all Perhaps this is a good time to mention the book on Prototype-Based Programming, which Springer assures me should be available in the US. This book has chapters covering concepts, languages (including Self and NewtonScript), research (including the Smalltalk to Self compiler), and a cool foreword (by Dave Ungar) and afterword (by Dave Thomas). My web page on the book includes a table of contents: http://www.mri.mq.edu.au/~kjx/pbook/ and it is also on amazon: http://www.amazon.com/exec/obidos/ASIN/9814021253/qid%3D925454401/002-01762… http://www.springer.de/cgi-bin/bag_generate.pl?ISBN=981-4021-25-3 James

1 0

Hardware for Self
by jdbell＠fareselaw.com 16 Sep '99

16 Sep '99

I want to play with Self a little. From what I can tell the only fully functional version is the original Sun Sparc version which can be found on the Sun web site. Unfortunately, I don't have a Sun. So, I'd like to buy a used machine which would run Self well. I don't know much about Sun machines - what hardware specs would you suggest? I haven't found anything about memory reqs etc other than the supported OS versions. Also, will Solaris 2.6 or Solaris 7 work? I basically just want to explore the system, and I'd really like to play with the multi-user aspects as well. Maybe a system that would support 4 simultaneous users well? As I understand it, the users would be using X, so they could be on Linux or NT or whatever, right? Intel boxes I have. I'm kinda counting on the assumption that the nice Self workstation of 1996 will be the inexpensive used box of today, since I'm on a bit of a budget... and of course I would be interested to hear if anyone is interested in selling a Self-class box. Thanks, Jerry Bell jdbell(a)fareselaw.com

3 2

Voting Results: Important Platforms for Self
by eGroups.com Poll Results 10 Sep '99

10 Sep '99

Here are the results of the vote: 1. Merced or Alpha 4 2. Solaris 4 3. ARM or Palm Pilot 5 4. Java VM 6 5. Macintosh 6 6. Linux 12 7. Windows 12

1 0

Re: Self on Linux
by Gordon Cichon 10 Sep '99

10 Sep '99

Hi, my vacation is over, I have to continue working on something else. Therfore I have less time now to continue with the Self port. I think that there is not missing too much to finally get a running system (with all the applications :-)). It all comes down to the stack walking code. In order to give others the chance to participate, too, I have put the stuff on the web server. Everybody who likes to see Self on Linux as soon as possible, and knows how to use a debugger is invited to help fixing the remaining problems. I will continue, too, of course. Maybe, I also made some mistakes... http://www.cichon.de/self/ -gordon -- ---------------------------------------------------- Gordon Cichon email: Gordon(a)Cichon.de ------------------------------------------------------------------------ eGroup home: http://www.eGroups.com/list/self-interest Free Web-based e-mail groups by eGroups.com

6 9

KNOW TYPES
by maria 08 Sep '99

08 Sep '99

Hello everybody: I have a new question for you: Does Self has got any menssage or intruction to know the type ( integer, char...) of an slot in run-time? please answer my question as soon as posible and thank you for yuor help. Maryah.

3 2

Threads
by Stefan Matthias Aust 03 Sep '99

03 Sep '99

Hi! In my attempt to beat Jecel in the egroups posting statistic (at least for one month :-) another brain-dump: This time about threads. For the Java-prototype of mySelf I'd like to support thread as this is one of Java's powers. It's one thing to make the object library thread safe. The other thing is the VM. It has to be thread safe on its basic level. If threads are simulated by the VM (as with Smalltalk's and probably also Self's processes), this isn't an issue. But for Java, it's interesting to use Java threads which are native on most platforms. This is a big plus if you want to implement servers or simply want a system that is responsive to the user while to interfaces external services. A Self VM is nearly stateless as all it does is pushing objects on a stack, either literals or activation objects for message sends and blocks. Each stack has its own stack and probably only a few variables if any. Method lookup is however critical. While more than one thread can access a central lookup cache as described in one of my previous emails, no thread may modify it while others try the same or what to use it. You need either thread-local caches (which could be a waste of memory) or a multiple-read, single-write lock. Right? While this seems easy, what must happen for inline caches? Does any thread need its own native method cache (assuming ICs are used with native compilation) or can the cache written in a way that is thread safe? Is there anything else to consider for VM threads? bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest September 1999