Self-interest December 1990

self-interest@lists.selflanguage.org

13 participants
20 discussions

Re: more on non-LIFO blocks
by Urs Hoelzle 20 Dec '90

20 Dec '90

> The only time you have to do anything special with a block is when > someone assigns it to a non-temporary variable or returns it. Correct. That means that you have to check, for every store into the heap, if the value being stored is a block. For some stores you'll be able to figure out that the value isn't a block, but I'm not convinced that this would be the common case. The check for blockness is likely to be relatively expensive (10 cycles). > Couldn't you modify self's gnarly inlining to handle this? I.e. > wouldn't inlining be able to track a lot of cases when it is known > that you don't assign a block to a non-temporary variable, return it, > or have it returned for you (like from one of your blocks)? This is true for all inlined blocks; they are never actually created and would be equally fast if we allowed non-LIFO blocks (NLBs). There's no fundamental obstacle which makes NLBs impossible for Self. What our discussion boiled down to was: - the desired MLB semantics are not clear (i.e. what would it mean to do a non-local return from a NLB? especially if the block was created in another process?) - NLBs would require considerable implementation effort - they are likely to add complexity to the system - the performance impact is not clear, but the store checks make it likely that the normal case (i.e. programs that do not use NLBs) is slowed down by the possibility of NLBs; on the other hand, we wouldn't need to mark blocks as 'dead' when exiting a scope. We (or at least I) are not fundamentally opposed to NLBs; I even believe that an efficient implementation is possible. But it's a low-priority issue. -Urs

1 0

Re: signals
by Urs Hoelzle 18 Dec '90

18 Dec '90

> I take it this means that the new compiler provides signal-handling > primitives of some sort? I don't remember this being mentioned at any > time. No and yes. All process support is provided via primitives, i.e. the compiler doesn't have much to do with it. And there is no signal handler in the Unix sense of the term. Rather, the TWAINS primitive *returns* whenever a signal occurs, i.e. control is returned from the process invoked by TWAINS to the process which called TWAINS (and there is always at most one process which can do the TWAINS). That is, the signal causes an involuntary transfer from the active process to the TWAINS process. Here's the current scheduler loop (in our system, not the released system) to illustrate this: [ | res. | currentProcess: schedule. "find next process to run" res: _TWAINS: currentProcess ResultVector: result. "transfer to it" res sendTo: self. "handle the event causing TWAINS to return" ] loop. The first two lines find the next process to run and transfer to it. When the timer expires, control is returned to the scheduler with the string 'signal' as the return value. The third line of the loop invokes the signal method of the scheduler which handles the specific signal(s) which caused the return of TWAINS (the vector result contains additional information about this). Similarly, if the current process caused a stack overflow, TWAINS would return with 'stackOverflow', and so on. As a last example, the code for "semaphore wait" yields the processor (after manipulating some queues) and thus causes a TWAINS to return with 'yielded'. Since the scheduler is the only process calling TWAINS, it cannot be interrupted itself by signals; this is a very nice property of our scheme which significantly simplifies the code. I.e. when no process is waiting in a TWAINS, signals are simply buffered by the VM, and no Self-level action occurs (but the next invocation of TWAINS will return these signals immediately). There is a _BlockSignals primitive for other (short) pieces of code which must not be interrupted. It is only provided to make the implementation of Semaphores simpler (and faster) and should not be needed by normal Self code (which will use Self-level synchronisation mechanisms like semaphores). > [Uh oh, here come the bounced messages....] Sorry for that - we get them too... maintaining a mailing list isn't easy :-( -Urs

1 0

yet more on processes
by ungar＠thoreau 17 Dec '90

17 Dec '90

While I completely agree with Urs and Peter, I also wanted to stick in my own 2 cent's worth. Here's the way I look at it: Self does even less scheduling than Smalltalk in the VM. This costs you in more process switches, but may make it easier to play with the scheduler. Like Smalltalk, our standard libraries do not allow for concurrency. Unlike Smalltalk, you can easily change the fundamental system objects and just file them in, since our compiler/parser is "below the line". (Of course this makes it harder to change Self's parser.) I am very pleased by the minimalism in the Self VM's treatment of processes. I hope it works out. By the way, on non-LIFO blocks: The whole issue of how far to reify activations and how much upward functionality to give blocks is a REAL toughie. The advantages are well known, but I think the costs are frequently underestimated. Specifically: performance. We would love Self to compete head-to-head with optimized C in runtime performance. I suspect that either reified activations or upward blocks would make this MUCH harder if not impossible. I do not believe that the work that the LISP community has done so far contradicts my view. For example, one LISP system that is considered pretty efficient (the subject of Kent Dybvig's SIGPLAN 90 paper on high-performance continuations) does not even use register windows on the SPARC--a MUST to compete with C on that machine. For regrettable, but good reasons, there is a dearth of head-to-head performance comparisons between C and LISP, and the ones we are aware of have used "shortcuts" like declarations or unsafe arithmetic functions. They do not give me any hope that, in the 1990's, we can approach optimized C performance AND do upward blocks in a language like Self. Sorry for the long answer, I hope to be proven wrong. David

2 1

signals
by trost%reed.BITNET＠Forsythe.stanford.edu 17 Dec '90

17 Dec '90

Urs Hoelzle writes: >...a TWAINS will transfer to the given process and run it >until some signal or special event occurs. Typically, this would be >'timer expired', 'process yielded', or a SIGIO signal. > >We have implemented a (rudimentary) scheduler and some basic >facilities like Semaphores and non-blocking I/O (all written in Self). I take it this means that the new compiler provides signal-handling primitives of some sort? I don't remember this being mentioned at any time. [Uh oh, here come the bounced messages....]

1 0

Re: Processes/non-LIFO blocks in the next release of Self
by Urs Hoelzle 14 Dec '90

14 Dec '90

> Can someone from the Self group provide some details on processes and > process scheduling in the next realease of Self. > > Shaun M. Smith (ssmith(a)joplin.mpr.ca / ssmith%joplin.mpr.ca(a)relay.ubc.ca) The VM provides a set of primitives to create and destroy processes and to program timers. In addition, there is one primitive (called TWAINS for "Transfer [to a given process] and WAIt for Next Signal") which does exactly what the name says. The VM does absolutely no scheduling; a TWAINS will transfer to the given process and run it until some signal or special event occurs. Typically, this would be 'timer expired', 'process yielded', or a SIGIO signal. We have implemented a (rudimentary) scheduler and some basic facilities like Semaphores and non-blocking I/O (all written in Self). Right now, the scheduler is a simple preemptive round-robin scheduler with no priorities, but since it is written in Self you can implement whatever scheduling policy you want. > Will the new system allow non-LIFO blocks? > -- Bill No. As explained by Craig, you can emulate some of the functionality with objects, and we feel that the benefits of non-LIFO blocks do not justify the additional complexity of implementation. -Urs

1 0

Processes in the next realease of Self
by ssmith＠mprgate.mpr.ca 14 Dec '90

14 Dec '90

Can someone from the Self group provide some details on processes and process scheduling in the next realease of Self. I'm wondering if it will be possible to have a process amongst a number of processes that is responsible for monitoring a unix socket. When there is nothing pending on the socket, this process would be suspended. When something is detected on the socket, then I'd want the process responsible to wake up and do whatever it's supposed to do. Essentially, what is the nature of the scheduling planned for Self? I was frustrated at one time with ParcPlace Smalltalk because "processes" were indeed independent threads of execution, but the scheduler (that resided in the VM) did not actually do time slicing. In order for the currently executing process to "lose control" of the CPU, it had to explicitly surrender it. At least this is the way I _thought_ it was happening. If anyone can enlighten me I won't argue. Shaun Shaun M. Smith (ssmith(a)joplin.mpr.ca / ssmith%joplin.mpr.ca(a)relay.ubc.ca) MPR Teltech, 8999 Nelson Way, Burnaby, BC Canada, V5A 4B5, (604) 293-5345 and Dept. Of Computer Science, University of British Columbia

2 1

Re: Catch & Throw
by Urs Hoelzle 14 Dec '90

14 Dec '90

> One problem I had with SELF's exit and exitValue was that it doesn't > seem to work when an _Eval is on the stack. This is indeed a bug, thanks for pointing it out. Non-local returns do not work across _Evals in the released system (i.e. if they should return to a frame above the Eval, they always terminate the entire program). I fixed that in our current system; we plan to release a new system sometime soon (hopefully January). > This makes it difficult to handle compile errors. The only approach I > can think of is to actually parse the expression! No; _Eval fails if there are parse errors, and you can catch the failure with a block as with any other primitive. For example, ')' _EvalIfFail: [ 'parse error' printLine] produces the output error: unexpected token on line 1, character 1 of "<a string>" found a ')' token expecting a token beginning a unary expression parse error (The first three lines are printed by the VM.) BTW, the new system will have processes; this makes it much easier to handle run-time errors in evaluators since you can fork a new process to evaluate the expression. If an error occurs during evaluation, only that process dies (but not the evaluator itself). -Urs

2 1

Re: Is the compiler necessary?
by craig 13 Dec '90

13 Dec '90

The compiler already works for the Sun3 as well as the Sun4. Porting to another Unix 68k-based architecture shouldn't be too much of a big deal; porting to MacOS would be more work. Porting to a new architecture is probably something that would take some time and good knowledge about the compiler. At the dawn of time we wrote an interpreter for Self in Smalltalk, but since then have always assumed compiler support. Toy programs would probably run fine in an interpreter, but real programs would probably be too slow. As an example, when our first compiler was coming on line, and didn't do much optimization, one of our benchmarks took about 6 hours to run. Nowadays it takes 5 seconds. I'd assume an interpreter would take even more time than the original unoptimizing compiler. Of course, if you'd like to experiment you could write your own Self interpreter. -- Craig Chambers

1 0

Is the compiler necessary?
by Sean.Levy＠CS.CMU.EDU 13 Dec '90

13 Dec '90

I have not had a chance to use SELF yet, so excuse me if this is an ignorant question. Is having the compiler absolutely necessary to use SELF? I ask because it seems that retargetting the compiler for other architectures will take time and work, and I don't expect it to happen right away. However, I need an environment that I can use EVERYWHERE, right now. Does the VM compile and work on architectures other than Sun4? If so, would that be enough for me to start working with SELF on other architectures? If so, can the source to the VM be made available? Is the speed of interpreted SELF so slow as to make this not a viable option? I see that much of the work on SELF has been put into the compiler, so I would not be surprised if this were the case. Cheers, { Sean } Mail: Sean Levy | EDRC | CMU | 5000 Forbes Ave | Pittsburgh, PA 15213 Campus: Hamburg Hall 2212, Ext. 2257 (+1 412 268 2257) EMail: snl+(a)cs.cmu.edu | ...!harvard!cs.cmu.edu!snl That which kills us does not make us stronger.

1 0

Re: self blocks
by craig 13 Dec '90

13 Dec '90

Blocks in Self are not upwardly mobile (not non-LIFO); they may only be passed downwards, not returned upwards. This is mostly an implementation restriction, not a deep language issue. But you could simulate non-LIFO blocks (at least in the situation you're describing) by manually building an object which represents the closure with its lexical environment: _AddSlots: ( | cond_gen: par1 = ( | closure | closure: ( | par1. value: par2 = ( par1 = par2 ). | ). closure par1: par1. closure ). | ) _AddSlots: ( | test_if_equals_4 = cond_gen: 4 | ) test_if_equals_4 value: 4 "prints true" (cond_gen: 'foo') value: 'bar' "prints false" -- Craig Chambers

1 0

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 December 1990