In addition to tail-call optimization, you also need a "contification"
pass, which removes intermediate functions in the SSA basic blocks where
possible. The observation is that if a function always returns to the same
point, then it can be turned into a continuation, which is exactly what an
SSA block is. Such a chain can then in certain situations be fused which in
turn makes it easier to expose loop information in the SSA graph.
However, considering Go's balance of producing fast compile times,
extensive CF/DF analysis is probably out of bounds.
My personal solution would be:
1. Get a machine with MASSIVE amounts of memory (initial bet: 128Gig and up)
2. CodeGen to the MLton compiler (mlton.org)
3. Do a whole-program compilation. This might take several coffee breaks.
4. Enjoy the fastest simulator ever.
However, for development you probably want something like SML/NJ because
your lead time could be measured in hours.
Another path is to cheat in the simulator. Replace circuitry with
hand-coded blocks (i.e., VLSI blocks) which doesn't simulate as much as
they run. I remember we did this at university some 15 years ago in order
to simulate circuits, because they would otherwise be too slow (mind you,
2000 hardware).
On Sun, Nov 12, 2017 at 6:12 PM Bakul Shah <ba...@bitblocks.com> wrote:
> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov <pet...@gmail.com> wrote:
> >
> > Generally, such a chain of statically-typed invocations will fall within
> the domain of the SSA optimizer and will be rewritten (theoretically)
> optimally.
> >
> >
> >
> > The issue arises when the invocation chain is recursive, e.g.
> >
> >
> >
> > func f1(x X) { ... f2(y) ... }
> > func f2(y Y) { ... f3(z) ... }
> > func f3(z Z) { ... f1(x) ... }
>
> Are you building a state-machine?
>
> Looks like what you really want is tail-call optimization....
> I don't think Go implements this. I tested this with two
> mutually recursive functions and the program ran out of stack
> space. IMHO you are better off using another language or a
> different scheme. For example, each function returns a
> function and its args as a struct to a driver routine.
>
> func f1(x X)(Fn, Arg) { ... return f2, &Arg{y} ... }
>
> A driver (much like an interpreter main loop) based approch
> will be somewhat slower.
>
> > (b) Is there any technical consideration prohibiting go packages from
> importing each other.
>
> When I needed this I defined a common package that declared a
> table and common types. Then each individual package added
> its own entries to this table via their init() function. The
> table can be a map or an array (in the latter case you'd have
> to define a constant for each package globally, which makes it
> less flexible).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
