Details on the ANI runtime
Ultimus
recap of the discussion of thread dispatching in ANI. Further
questions / requests for clarification are welcome.
In ANI, there is a static pool of worker threads whose action is
orchestrated by an intelligent administrator thread. Worker threads
are dispatched and routed (in real-time) by the administrator to
sections of pipes which I refer to as "pipe chunks".
Each pipe chunk is its own unit of execution -- by "pipe chunk", I
mean anything delimited by curly braces and semicolons. This could
amount to something as short as an expression followed by a send,
which is typically under 100 instructions. There might be
mispredicted
branches and whatnot, of course, but that's of out of the program's
hands. Poorly implemented mutexes would blow this up, too, but for
the
most part, ANI's scheduling is synthesized statically and routed by
the administrator thread, eliminating the need for mutex locks (in
the
most common cases). Thus, threads execute raw pipe chunks (and
nothing
else), which last only about 100 instructions each, give or take
depending on the particulars of the OS scheduler.
If we're going to get technical, though, the crazy thing is that
there
isn't usually any full "dispatching" going on; the administrator
thread routes pipes in real-time by (part statically, part JIT)-
patching jump points with a bit of buffer room, working ahead of the
execution so that threads literally jump from one pipe chunk to
another without any threading overhead whatsoever (the administrator
takes care of the dirty work, and this approach incurs nearly zero
overhead since it's running on a separate processor). Thus, a thread
doesn't need to return for redispatch in most cases if the buffering
is sufficient (it only needs to redispatch if the administrator isn't
able to patch the route quick enough and it takes an unpatched jump,
which defaults to a "return-for-fresh-dispatch" function).
The administrator thread (the core of the runtime) does this
dispatching intelligently, attempting to avoid contention/deadlock
whenever possible, and it does it at real-time execution speed. Thus
perhaps instead of "high-speed", I should be saying "real-time",
"massively parallel", and "minimal-idling", but most people probably
wouldn't understand that.
As for this being dependent on the number of processing elements
available, of course: the runtime spawns an amount of worker threads
such that cores are maximally utilized (usually one worker thread per
core), though the user can tell the compiler (through options or what
have you) to produce a program that uses as many or as few threads as
they want if they want to hand-optimize for their use case.
On Jan 26, 8:13 am, davidy <da...@yorkage.com> wrote:
> OK, I'm starting to get the picture here. you have chunks that are
> roughly equivalent to a "basic block" -- a segment of code that is
> known to lie entirely within one thread of execution (whether or not
> it actually contains any branches). It could call a "pure" function
> but nothing with side effects, and no external APIs [the precise
> limits would take some thought.] The typical length of one of these is
> at most a few hundred instructions (including function calls?).
You've got the right idea, except that pipe chunks do *not* have any
function calls, by definition: in a sense, pipe chunks == functions.
In the case of filters, for example, which seem like function calls,
the compiler simply shatters the pipe in two at the filter invokation
point: the part before the filter invokation, and the part after it.
The two resulting pipes are joined by an implicit latch (of the type
of the filter) with a corresponding send to the filter/delatch from
the return value at the splice points between the shattered pipes.
So in ANI, there are no "function calls", and hence there is not need
for a traditional execution stack, further reducing bookkeeping
overhead.
Of course, this all breaks with externel APIs, as you said, which is
why I'm trying to make ANI self-sufficient so such things aren't
necessary. Further, using external APIs would kind of throw ANI's
guarantees like safety and deadlock-freedom out the window, which is
why I'm trying to encapsulate API functionality into mere interfaces
to latches/streams rather than arbitrary messing with internal ANI
pipelines.
> The traditional approach would be that this code would be allowed to
> execute until it reached a critical section or other kind of
> synchronising element. At this point the scheduler would decide
> whether to suspend or not, and which thread should run next. The
> placement of these critical sections is a programmer responsibility.
The scheduler doesn't need to wait for anything; the dependencies are
across pipes, not inside them. Therefore, just routing pipes
appropriately eliminates the need for *explicit* critical sections or
synchronizing elements.
Actually, all of the ANI code written on the site has critical
sections and synchronization all over the place; it's just
transparent
and naturally implied by the language, and the compiler extracts this
information, synthesizing it into a deadlock-free control graph.
Delatching something is a form of synchronization. So is flushing a
stream or sending somewhere; programmers probably won't realize this,
and that's the whole point. ANI is a way of making massively parallel
programming easy and intuitive.
> Your approach brings in 2 innovations. One is the "pipe chunks" which
> you derive from the peculiar syntax of the language and compile-time
> analysis. The other is "predictive scheduling". Rather than waiting
> for a chunk to run to completion and call the scheduler to find out
> what to do next, the scheduler predicts what it should do and
> manipulates the execution path so that execution switches smoothly
> from one chunk to another.
Exactly. The scheduler lays out the path ahead of the threads of
execution so they can keep going without waiting to stop for a
scheduling decision, if all goes well.
> The pipe chunks are an obvious implication of the language. In a
> sense, the language syntax is what you have to create in order to get
> the chunks, which are what you wanted in the first place.
Quite right. The research/theory came first, then I designed a
language to try and exploit the ideas in a user-friendly way.
> The predictive scheduling is far from obvious and perhaps not even
> worthwhile. Some arguments against:
> 1. It would seem to involve a massive overhead: 1/Nth of N threads/
> processors lost to glorified bookkeeping. I certainly can't see the
> point on a 2 processor machine of dedicating one processor to making
> sure the other one doesn't stall.
You're quite right. But the point is that ANI is designed with the
100-
core machines of 2020 in mind. We have more and more processors, and
a
lot of the time, they are idling and being wasted anyway; this
problem
is only going to get worse and worse, and ANI is an attempt to solve
it.
So, if you reserve one extraneous core (that would probably be idling
otherwise) for bookkeeping so that ten others could be utilized
extremely efficiently, my views is that it's more preferable than
having a single core used to execute a monothreaded app and 10 others
being wasted doing nothing.
> 2. It sounds fiendishly difficult to design, code, debug etc. Is the
> benefit worth the cost?
Not fiendishly difficult, but probably challenging. I do have a lot
of
compiler / parallel / real-time programming experience going in. And
the point is that I have to do this only *once* in writing anic, and
then for the most part parallel programming is a solved problem and
doesn't have to be worried about again if you accept the dataflow
paradigm. I think the benefit if definitely worth the cost.
> 3. Programs based on the technology will be hard to test & debug.
The compiler would be hard to debug, yes. But once it's stable, we
don't have to worry about parallel programming again, and I think
that's a noble goal.
If you mean using GDB to debug user programs written in ANI then
you're probablyright. It would require a rethinking of how we view
program execution (but then again, that's at the heart of ANI
itself).
Do keep in mind though that printf-type debugging is still very much
possibly and unintrusive; just stick a "std.out" anywhere in ANI code
and you get the current value in a pipe being sent to a log. Further,
a lot of parallel programming bugs are eliminated because the runtime
guarantees freedom from deadlock. So perhaps it won't be to bad.
> 4. It would seem to rule out a number of possible implementation
> platforms including JVM, CLR, etc.
Probably, though I'm still investigating this. Obviously it would be
possible top port to those platforms (with emulation or otherwise),
though a lot of ANI's benefits in parallelism might be lost.
> 5. Many "real" programs will do much of their work in external
> libraries or APIs, where it probably doesn't work.
If the interfacing is clean (APIs interact with latches/streams
themselves, and nothing else), it's still fairly easy to do. Of
course, it would just make ANI a lot slower if you used such
interfacing, but this is a relic of the older languages, and really
can't be changed.
> I assume you have answers to these objections, which may help me to
> understand better. My real point is: the languages and "pipe chunks"
> may be a sufficient innovation to justify ani without predictive
> scheduling. The good enough may get bogged down in the quest for the
> excellent.
My view is that there are already "good enough" systems out there.
The
problem is that they won't scale well with the future evolution of
computing towards massive parallelism, and that's the nice that ANI
is
trying to fill.
> Do you have a defined instruction set, code fragments and runtime API
> yet?
Loosely, and though it's been given years of thought, little of it is
written down simply because I don't have the time to invest into a
raw
spec at this point.
But these are largely small concerns. Porting between instruction
sets
won't be too bad, especially if I leverage GCC's instruction matching
back-end to do it for me. The biggest problems, I think you'll agree,
are in the application of the runtime / compilation ideas rather than
worrying about platform specifics, which are largely a solved problem
nowadays.
Cheers!
Adrian
davidy
> I'm breaking this topic off into a new post.
Good idea. But I'm planning to step outside just details about the
runtime and look at any of the low level architectural details, if you
don't mind.
> You've got the right idea, except that pipe chunks do *not* have any
> function calls, by definition: in a sense, pipe chunks == functions.
I would really like to see some fragments. Are you saying that the
compiler generates only sequences of assembly language instructions
and absolutely never emits calls to any internal runtime functions?
What about memory allocation for object instances?
> So in ANI, there are no "function calls", and hence there is not need
> for a traditional execution stack, further reducing bookkeeping
> overhead.
So you allocate expression temporaries statically (in some kind of
task local storage)?
> Of course, this all breaks with externel APIs, as you said, which is
> why I'm trying to make ANI self-sufficient so such things aren't
> necessary. Further, using external APIs would kind of throw ANI's
> guarantees like safety and deadlock-freedom out the window, which is
> why I'm trying to encapsulate API functionality into mere interfaces
> to latches/streams rather than arbitrary messing with internal ANI
> pipelines.
This is a biggie. I doubt that most people who read your intro will
realise that your system is critically dependent on a complete
reimplementation of a runtime environment in ani. You are not talking
about a scripting language like perl or python as a layer over C/C++.
This is more like LISP or Smalltalk: you need to have a complete
runtime environment built in ani code from top to bottom. All the
string classes, collection, maths, encryption, file system,
persistence, internet access, protocols and anything I missed have to
be rewritten from scratch. As well as a debugger, tracing and some
kind of IDE support. As it happens I've done something very like that,
and I'm here to tell you it's a big job.
You're going to need some help.
> You're quite right. But the point is that ANI is designed with the
> 100-
> core machines of 2020 in mind. We have more and more processors, and
> a
> lot of the time, they are idling and being wasted anyway; this
> problem
> is only going to get worse and worse, and ANI is an attempt to solve
> it.
This is another biggie. You should say right up front that the system
is designed for future hardware: 4 processors get you a ticket to play
but the big benefits come with 64 or 256 or more, somewhere in the
future. You should also say that it is not intended for problems that
are instrinsically parallel (like pixel operations on a GPU or a Web
server with 1000 sessions). It is intended for scalar problems that
are heavy on CPU usage, such as what? Natural language processing?
Advanced image analysis? AI? Autonomous machines & robotics?
> My view is that there are already "good enough" systems out there.
> The
> problem is that they won't scale well with the future evolution of
> computing towards massive parallelism, and that's the nice that ANI
> is
> trying to fill.
OK, I' ve brought up all the objections I can think of and those are
good answers. They certainly help me to understand better, but I still
think you have a job to do in explaining what it's all about and why,
without resorting to marketing speak or hand waving, to attract people
to your bazaar.
> Loosely, and though it's been given years of thought, little of it is
> written down simply because I don't have the time to invest into a
> raw
> spec at this point.
> But these are largely small concerns. Porting between instruction
> sets
> won't be too bad, especially if I leverage GCC's instruction matching
> back-end to do it for me. The biggest problems, I think you'll agree,
> are in the application of the runtime / compilation ideas rather than
> worrying about platform specifics, which are largely a solved problem
> nowadays.
I hope you will write some notes on these topics at some stage. I am
not very familiar with gcc, except we use it for some of our ports.
Most of my code generation experience has been with stack-oriented VMs
but yes, I would encourage you to take that kind of route.
The problem for me at least is that the language is just syntactical
sugar over the really interesting stuff, and the system doesn't seem
to be far enough along for lots of other people to help. Can you give
a summary of what has been done, what's finished, what's next and
which areas can realistically be farmed out and how?
dy
Ultimus
> On Jan 27, 7:03 am, Ultimus <ulti...@gmail.com> wrote:
>
> > I'm breaking this topic off into a new post.
>
> Good idea. But I'm planning to step outside just details about the
> runtime and look at any of the low level architectural details, if you
> don't mind.
By all means. My definition of "runtime" as used here is quite broad
anyway.
>
> > You've got the right idea, except that pipe chunks do *not* have any
> > function calls, by definition: in a sense, pipe chunks == functions.
>
> I would really like to see some fragments. Are you saying that the
> compiler generates only sequences of assembly language instructions
> and absolutely never emits calls to any internal runtime functions?
> What about memory allocation for object instances?
Yes, you are correct; the assembly never calls the runtime or other
code (everything necessary is inlined right in). If you want to get
"call" semantics, you invoke a filter; the implementation considers
this to split the pipe into two fragments however. An example:
s = [[string\]];
"Hello, World!" ->s;
\s string.toCaps ->std.out;
This example contains 3 code fragments. The first line itself isn't
ever "executed"; it's not a fragment, it's just a binding. The second
line consists of one fragment that does a send. The third line seems
like one fragment but it's really broken down into two by the
compiler: The first is a delatching of s followed by a send to the
filter. The second is delatching the return result of the filter and
sending to to std.out.
So as you can see, fragments can be really tiny and fine-grained.
That's why the runtime needs to be able to route threads through them
at high-speed (in this case, the runtime would "glue" together several
pipes by patching jump addresses so that threads don't need to return
for dispatch in each case).
Memory is allocated for the most part statically at compile-time. The
language syntax was designed so that this would be possible (and
natural). When you use the [[ ]] syntax, the compiler reserves room in
the virtual memory space for your object at a specific location, and
this is hard-coded into the assembly. The exception is streams, which
are basically bounded buffers/arrays of objects. These are also
statically allocated with a configurable inital capacity, but they can
be dynamically resized at runtime if necessary (such as when we want
to insert an array element into an arbitrary point off the end of the
stream).
>
> > So in ANI, there are no "function calls", and hence there is not need
> > for a traditional execution stack, further reducing bookkeeping
> > overhead.
>
> So you allocate expression temporaries statically (in some kind of
> task local storage)?
Things are kept in registers, if space allows. Failing that, yes,
temporaries will leak into statically allocated task-local storage.
>
> > Of course, this all breaks with externel APIs, as you said, which is
> > why I'm trying to make ANI self-sufficient so such things aren't
> > necessary. Further, using external APIs would kind of throw ANI's
> > guarantees like safety and deadlock-freedom out the window, which is
> > why I'm trying to encapsulate API functionality into mere interfaces
> > to latches/streams rather than arbitrary messing with internal ANI
> > pipelines.
>
> This is a biggie. I doubt that most people who read your intro will
> realise that your system is critically dependent on a complete
> reimplementation of a runtime environment in ani. You are not talking
> about a scripting language like perl or python as a layer over C/C++.
> This is more like LISP or Smalltalk: you need to have a complete
> runtime environment built in ani code from top to bottom. All the
> string classes, collection, maths, encryption, file system,
> persistence, internet access, protocols and anything I missed have to
> be rewritten from scratch. As well as a debugger, tracing and some
> kind of IDE support. As it happens I've done something very like that,
> and I'm here to tell you it's a big job.
The libraries aren't a big burden. Personally, I love writing in ANI
and I'll gladly write the necessary library support. The debugging
stuff is more complicated because, yes, ANI is very untraditional in
its approach and reconciling the architectural differences enough to
get debuggers to work with it won't be trivial. IDE won't be too bad
though; ANI is actually a very small language with straightforward
semantics that follow principle of least surprise. It's really only
the debugging functionality that will present a challenge.
>
> You're going to need some help.
This I know.
>
> > You're quite right. But the point is that ANI is designed with the
> > 100-
> > core machines of 2020 in mind. We have more and more processors, and
> > a
> > lot of the time, they are idling and being wasted anyway; this
> > problem
> > is only going to get worse and worse, and ANI is an attempt to solve
> > it.
>
> This is another biggie. You should say right up front that the system
> is designed for future hardware: 4 processors get you a ticket to play
> but the big benefits come with 64 or 256 or more, somewhere in the
> future. You should also say that it is not intended for problems that
> are instrinsically parallel (like pixel operations on a GPU or a Web
> server with 1000 sessions). It is intended for scalar problems that
> are heavy on CPU usage, such as what? Natural language processing?
> Advanced image analysis? AI? Autonomous machines & robotics?
Actually, ANI would work very well for applications that are already
parallel; the same parallelism would be exploited (and perhaps better
tuned) in ANI. ANI might not give as large a benefit, but it would
still be there.
ANI is intended as a general-purpose language that turns all sorts of
problems into the highly parallelized cases, without the programmer
having to think about this. So to ask specifically what the
applications are is to kind of miss the point; The point is that ANI
makes almost any program parallel for you, and you shouldn't need to
think about the specifics of your application domain for it to just
work. Within a few years, all of the platforms out there will be based
around parallelism (a lot already are), and that's when languages like
ANI will really be the only practical way to go.
>
> > My view is that there are already "good enough" systems out there.
> > The
> > problem is that they won't scale well with the future evolution of
> > computing towards massive parallelism, and that's the nice that ANI
> > is
> > trying to fill.
>
> OK, I' ve brought up all the objections I can think of and those are
> good answers. They certainly help me to understand better, but I still
> think you have a job to do in explaining what it's all about and why,
> without resorting to marketing speak or hand waving, to attract people
> to your bazaar.
You're right that I do have explaining to do. I'm not a marketer
though, and my main goal isn't to attract people. ANI is an experiment
in some programming ideas that I find fascinating, and more a
philosophical treatise than a product I'm trying to sell.
That said, more support is always good for such projects, so I
wouldn't mind more help. It's just at this point, I'm trying to juggle
a lot of things (in the project and outside of it) and I'm trying to
prioritize, meaning things like marketing fall off the radar.
>
> > Loosely, and though it's been given years of thought, little of it is
> > written down simply because I don't have the time to invest into a
> > raw
> > spec at this point.
> > But these are largely small concerns. Porting between instruction
> > sets
> > won't be too bad, especially if I leverage GCC's instruction matching
> > back-end to do it for me. The biggest problems, I think you'll agree,
> > are in the application of the runtime / compilation ideas rather than
> > worrying about platform specifics, which are largely a solved problem
> > nowadays.
>
> I hope you will write some notes on these topics at some stage. I am
> not very familiar with gcc, except we use it for some of our ports.
> Most of my code generation experience has been with stack-oriented VMs
> but yes, I would encourage you to take that kind of route.
The dataflow paradigm is extremely stack-oriented, actually, and that
why I think a VM implementation would be awesome if the JIT stuff
could be figured out.
>
> The problem for me at least is that the language is just syntactical
> sugar over the really interesting stuff, and the system doesn't seem
> to be far enough along for lots of other people to help. Can you give
> a summary of what has been done, what's finished, what's next and
> which areas can realistically be farmed out and how?
Done:
Language analysis, type checking is the only thing that's incomplete.
Not done:
Tutorial, spec, code gen, runtime, libraries.
The most farmable of these are the documentation (tutorial, spec) and
the libraries. I know that might sound strange, since I'm the one
designing the language, but truth to be told not all of it is 100% set
in stone yet, and with people like Dan Kersten having a nearly
complete grasp of the language already, I'd be comfortable having
someone help me out with the spec and docs to a large extent. I'll
read through and fix the bugs, of course, but I think there are people
out there who could do significant work on these things without me
looking over their shoulder.
The libraries are a similar story, though they would probably need to
come second (after more rigid docs are out). I can easily see others
writing them and me giving the go-ahead. Besides, once the compiler's
done, verifying and debugging the libs will be relatively easy. The
main point for trying to implement libraries even before the compiler
is done is that the docs will need to be debugged and clarified. The
language needs broader real-world testing, preferably before a complex
runtime system is made only to have us realize that the language
contains an oversight that requires throwing away a lot of work.
The code gen/runtime are too fresh to have external work on them done
at this point, so I'll do that, though if anyone wants to work through
the current compiler code and get to know the structure enough to be
able to work on it, well, that would be a very pleasant surprise :-).
>
> dy
davidy
> code (everything necessary is inlined right in). If you want to get
> "call" semantics, you invoke a filter; the implementation considers
> this to split the pipe into two fragments however. An example:
That's pretty obvious at the user level. It's not so obvious that you
can inline everything implied by the language semantics and code
generation, such as memory allocation and expression evaluation.
> Memory is allocated for the most part statically at compile-time. The
> language syntax was designed so that this would be possible (and
> natural). When you use the [[ ]] syntax, the compiler reserves room in
> the virtual memory space for your object at a specific location, and
> this is hard-coded into the assembly. The exception is streams, which
> are basically bounded buffers/arrays of objects. These are also
> statically allocated with a configurable inital capacity, but they can
> be dynamically resized at runtime if necessary (such as when we want
> to insert an array element into an arbitrary point off the end of the
> stream).
Yes, allocaing dynamic objects and resizing collections are the kind
of thing I had in mind.
> The libraries aren't a big burden. Personally, I love writing in ANI
> and I'll gladly write the necessary library support.
You may like it, but that won't make it get done faster. Did you plan
to write regex yourself? What about printf? These are big tasks to get
right, and they need a lot of test cases, quite apart from the
documentation. My experience has been that the runtime is always a
bigger job than the compiler.
> The debugging
> stuff is more complicated because, yes, ANI is very untraditional in
> its approach and reconciling the architectural differences enough to
> get debuggers to work with it won't be trivial.
Indeed. However, I would not personally be thinking of anything like
gdb. The only debuggers I use these days are the ones built into an
IDE, such as VS, Eclipse or Netbeans. If you go that way, the only
critical thing is a debugging API they can work with. If you go with
the CLR/JVM then you don't really get much choice.
> IDE won't be too bad
> though; ANI is actually a very small language with straightforward
> semantics that follow principle of least surprise. It's really only
> the debugging functionality that will present a challenge.
You're probably right, but my view is that something better than
minimal support in an IDE goes a long way towards getting people to
use it. You need symbol table for navigation and for debugging.
> Actually, ANI would work very well for applications that are already
> parallel; the same parallelism would be exploited (and perhaps better
> tuned) in ANI. ANI might not give as large a benefit, but it would
> still be there.
>
> ANI is intended as a general-purpose language that turns all sorts of
> problems into the highly parallelized cases, without the programmer
> having to think about this.
Exactly. You don't want to try to compete with cases where the
existing parallelising tools are working reasonably well, like GPU and
Beowulf apps. Concentrate on the ones they can't touch. But it has to
be cases where speed of executing code does matter.
> So to ask specifically what the
> applications are is to kind of miss the point; The point is that ANI
> makes almost any program parallel for you, and you shouldn't need to
> think about the specifics of your application domain for it to just
> work. Within a few years, all of the platforms out there will be based
> around parallelism (a lot already are), and that's when languages like
> ANI will really be the only practical way to go.
I'm not sure that's so. The vast majority of business apps are not CPU
dominated. Either they are limited by IO capacity or they are
scripting lots of system APIs or they are heavily dependent on big
packages like a database or Web server. There is no traction for ani
because there isn't a problem of the kind it can fix.
Then there are tools like a Web browser, office suite, IDE, database
where some parallelism does matter but the code is already written. no-
one is going to rewrite Firefox in ani any time soon.
You need to find problems where making it parallel actually matters
and where good solutions do not already exist. That's where I would
expect your early adopters to come from (other than language
enthusiasts like me).
How about some good samples? Finding primes, factorisation, Fibonacci
numbers, pi, tree walking, matrix inversion, Fourier, map-reduce: any
ideas you can use? My current system is 4 core plus hyperthread. I
would love to see 8 (or 7) processors running at 100% spitting out
primes.
> You're right that I do have explaining to do. I'm not a marketer
> though, and my main goal isn't to attract people. ANI is an experiment
> in some programming ideas that I find fascinating, and more a
> philosophical treatise than a product I'm trying to sell.
No, you shouldn't try to get into marketing-speak, but at the same
time you do need to tell other people what you're doing if you want
them to get involved. The vision you project and the words you use
will have a large effect on how people react, and I think you need to
spend at least a little time on that aspect. I think I "get it", but
it's taken some effort and I bring useful background. Don't assume
everyone can see where you're headed if you don't tell them.
> The dataflow paradigm is extremely stack-oriented, actually, and that
> why I think a VM implementation would be awesome if the JIT stuff
> could be figured out.
I thought you didn't use a stack?
> The most farmable of these are the documentation (tutorial, spec) and
> the libraries.
Best of luck getting anyone to write a spec. AFAIK ruby still doesn't
have one. If you don't write it because you need it, it probably won't
get done.
Tutorials, libraries: absolutely, but how to get started before you
have a working system? I think I get the language, but until I can
write it and run the programs, I won't be sure.
> The
> language needs broader real-world testing, preferably before a complex
> runtime system is made only to have us realize that the language
> contains an oversight that requires throwing away a lot of work.
Absolutely. But surely you need the core of a working runtime, or it's
all too virtual?
>
> The code gen/runtime are too fresh to have external work on them done
> at this point, so I'll do that, though if anyone wants to work through
> the current compiler code and get to know the structure enough to be
> able to work on it, well, that would be a very pleasant surprise :-).
I've read some of it, but it's a bit impenetrable in places. Partly
this is because it's table driven, partly because the grammar has no
actions so it's not easy to see what kind of tree you're building,
partly because I don't really understand the type system. You've got
heaps of low level comments but not much in the way of high level
overview, so there's a fair bit of semmer I don't understand. There
seems to be quite a bit to do still.
dy
Daniel Kersten
Adrian, can you implement a "test" runtime for the time being? Like,
instead of performing all the magic you described above, dumps each
pipe into a static thread or something. Inefficient, sure, but at
least it'll give everyone something to play and experiment with while
you work on the real runtime.
David is absolutely correct here - I'm willing to help write docs and
libraries, but not until I have something I can experiment with. I've
been purposely holding off writing any ANI code at all, waiting for a
working compiler. I don't need it to be optimal, just something crude
so I can observe actual running code. I'm sure others are in a similar
position.
>>
>> The code gen/runtime are too fresh to have external work on them done
>> at this point, so I'll do that, though if anyone wants to work through
>> the current compiler code and get to know the structure enough to be
>> able to work on it, well, that would be a very pleasant surprise :-).
>
> I've read some of it, but it's a bit impenetrable in places. Partly
> this is because it's table driven, partly because the grammar has no
> actions so it's not easy to see what kind of tree you're building,
> partly because I don't really understand the type system. You've got
> heaps of low level comments but not much in the way of high level
> overview, so there's a fair bit of semmer I don't understand. There
> seems to be quite a bit to do still.
>
> dy
>
--
Daniel Kersten.
Leveraging dynamic paradigms since the synergies of 1985.
Dominic Morneau
> instead of performing all the magic you described above, dumps each
> pipe into a static thread or something. Inefficient, sure, but at
> least it'll give everyone something to play and experiment with while
> you work on the real runtime.
I agree, and I'd suggest coding a prototype of a very simple compiled
program (eg. the calculator clock) in plain old C before working on
assembly & code generation. It would validate the model and provide a
good demo.