headers
RE01 Rice Brian T. EM2 | 19 Sep 2001 06:57
Picon

More Arrow Progress (sorry, no code yet)

Hello all,
Well, I assume that those of you familiar with my current situation can also
imagine how current world events are not making my life any easier for
programming and research.

However, I do guarantee that a lot of good progress is happening. The
changes are being nicely factored for clarity so that it should be fairly
simple to generate some v0.2 documents for when I can release the code.
Everything about arrow frames, object graphs, and the SEXP evaluator that I
didn't release is being re-factored. The frames and object wrapper graphs
were just primitive arrangements for MOPs of various kinds, and the
frameworks for those have been stretched and re-thought much for the better,
especially as I toy with evaluation models and see where things break
conceptually.

Incidentally, I finally re-named the ambiguous-sounding "meta graph" concept
to "inclusion graph" or inclusion representation, so that meta can just be
an informal term. This was really confusing for a lot of you and I apologize
that I didn't get the ideas of meta-level aspects worked out properly
sooner.

There are also a lot of fixes that I'd like to get out, for example a lot of
the basic libra-related operations and queries are now type-safe to a very
strong degree (of course Smalltalk reflective facilities can bypass this).
Unfortunately this won't come about for a little while; I'll see what I can
arrange to get it out soon.

Also a general strategy is starting to form that's bigger than just an
interactive evaluator. Maybe I'll be able to elaborate on that soon.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Armin Rigo | 20 Sep 2001 18:29
Picon
Picon
Favicon

Progress on a Python compiler

Hello Brian, hello everybody,

A short note about my current work, not directly related to Tunes. I am
progressing on a kind of compiler for the Python language, "Psyco".

It is actually a kind of just-in-time compiler, working at run-time. It
consists of two parts: a language-independent "glue" part (which I more or
less finished), and the inner loop of the Python interpreter rewritten in
a special, resticted language. The "glue" part executes Python programs by
running the interpreter, but not in the common way. The run-time data are
split into what must be known to produce good processor code, and what
need not be. Typically, we need to know at least which Python code to
interpret before we can make good processor code that performs similarily;
in the case of Python we will probably also need to know the type fields
of the actual Python objects fed to the Python code; the processor code
can be very efficiently optimized depending on the type. On the other
hand, if the Python objects are, say, integers, then the same processor
code can easily manipulate all possible integer values. The "glue" code is
responsible for choosing which data goes into which category, and managing
caches of the produced code. The Python-dependent part of the code either
makes computations at compile-time (for compile-time-known values) or
emits code to do it at run-time (for the rest).

The choice between the two categories of data is not done statically; I
mean, I didn't say "Python code and type fields are in category 1, the
rest in category 2", which would amount to writing a JIT compiler with
type-analysis. No; I let this separation be done based on the uses of the
data. In two words, if I have a "switch" on data, or a call to function
pointer, then knowing the data at compile time enables significant
improvements, so I mark that data as "category 1"; as long as this does
(Continue reading)

Permalink | Reply | 1 comment |
headers
mdanish | 20 Sep 2001 19:56
Picon

Re: Progress on a Python compiler

On Thu, Sep 20, 2001 at 06:29:09PM +0200, Armin Rigo wrote:
> 
> A short note about my current work, not directly related to Tunes. I am
> progressing on a kind of compiler for the Python language, "Psyco".
> 

Not to be confused with the CMU Common Lisp compiler, "Python"

;)

--

-- 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish                         email: mdanish <at> andrew.cmu.edu ;;
;; OpenPGP public key available from:        'finger mrd <at> db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Permalink | Reply | 0 comments |
headers
Chris Moline | 26 Sep 2001 21:06
Picon

Cool project!!

Hi,

I have been browsing through your website and I just wanted to say that
you have a lot of cool stuff in there. I am interested in joining your
project. I know a little scheme and am currently learning common lisp
and the oskit. I am thinking of developing an os development enviroment
using lisp, oskit, and possibly a pc emulator. Is anyone working on
something similar or something like this exist?? Would this be of use to
you??

I look forward to having fun with you guys.

Sincerly,
Chris Moline
Permalink | Reply | 0 comments |
headers
RE01 Rice Brian T. EM2 | 1 Oct 2001 01:31
Picon

Cool project!!

Welcome.

> Hi,
> 
> I have been browsing through your website and I just wanted to say that
> you have a lot of cool stuff in there. I am interested in joining your
> project. I know a little scheme and am currently learning common lisp
> and the oskit. I am thinking of developing an os development enviroment
> using lisp, oskit, and possibly a pc emulator. Is anyone working on
> something similar or something like this exist?? Would this be of use to
> you??
> 
> I look forward to having fun with you guys.
> 
> Sincerly,
> Chris Moline

There *was* a LispOS project which is now defunct, if I remember right. I
and one or two others on this list personally own Lisp machines which have
the native Genera operating system entirely written in (two separate
dialects of) Lisp, and these systems contain a lot of lessons to learn from;
however the licensing options are very restrictive.

The Vapour OS project uses Scheme, and have some decent progress, but the
last time I contacted the author he was busy with some other projects. You
could probably benefit most from talking to him.

There is also the Squeak project which includes a Smalltalk VM that
generates C-code from its self-hosted VM simulator, in order to make,
extend, and port its VMs. The SqueakOS and SqueakNOS projects are attempting
(Continue reading)

Permalink | Reply | 0 comments |

Gmane