Two questions 
Author Message
 Two questions

Hi,

I'm interested in learning how d2c works, and so I've downloaded the
source code. Dylan's system of breaking code into libraries and
modules makes reading the source a less daunting task than I feared,
but I still have two questions before beginning in earnest:

o How do I subscribe to gd-hackers?

  The CGI on the Gwydion homepage wasn't working, and email to the
  majordomo address listed also didn't work.

o Is there a recommended reading order to the pieces of the compiler?

  So far I've just been looking at the libraries, but I will soon
  want to look at the compiler itself, and I was wondering if there
  was a preferred order due to dependencies in the code.

Thanks.

Neel



Mon, 21 Jan 2002 03:00:00 GMT  
 Two questions

Quote:

> Hi,

> I'm interested in learning how d2c works, and so I've downloaded the
> source code.

Excellent!  The more the merrier!

Quote:
> o How do I subscribe to gd-hackers?

>   The CGI on the Gwydion homepage wasn't working, and email to the
>   majordomo address listed also didn't work.

The machine that does both is down :-(

This is extremely sad, and I'm afraid is giving a bad impression of the
Gwydion project which is actually alive and well and makin exciting
progress.

If I had a permanent connection I'd offer to host it...

Quote:
> o Is there a recommended reading order to the pieces of the compiler?

>   So far I've just been looking at the libraries, but I will soon
>   want to look at the compiler itself, and I was wondering if there
>   was a preferred order due to dependencies in the code.

Good question.  If you find out then let me know :-)

I agree that the runtime libraries in src/d2c/runtime/dylan and to a
lesser extent in src/common are a good place to start, and that's what
I've mostly been doing so far -- there are some significant improvements
that can be made to d2c without going anywhere else!

Also, time spent compiling small programs and examining the resulting C
code to see how various features are implemented is rewarding.

I'd look at src/d2c/compiler/main next.  It's pretty small and you get the
overview on how and when things are done.

Then src/d2c/compiler/base.  *Everything* depends on it.

src/d2c/compiler/(parser|front|cback) I'm basically ignoring at the moment
-- they Just Work.  That's not to say that there is nothing important to
do there -- Peter's work on generating C code for the static heap instead
of asm is a prime example.

Which leaves src/d2c/compiler/convert and src/d2c/compiler/optomise which
is where I think the bulk of the "interesting" stuff goes on.

-- Bruce



Mon, 21 Jan 2002 03:00:00 GMT  
 Two questions

Quote:


>> o Is there a recommended reading order to the pieces of the compiler?

>I agree that the runtime libraries in src/d2c/runtime/dylan and to a
>lesser extent in src/common are a good place to start, and that's what
>I've mostly been doing so far -- there are some significant improvements
>that can be made to d2c without going anywhere else!

Wow. I've just looked in src/d2c/runtime/dylan and am seriously
impressed. Every piece of code I've looked at is SO clean. There's so
little cruft that I'm comprehending most things on the first pass.

Is there a todo list? I had just hoped to learn a little about how d2c
worked, but now it looks like I might actually comprehend enough to
make some useful contributions.

Neel



Mon, 21 Jan 2002 03:00:00 GMT  
 Two questions
....

Quote:
> > - improve inlining analysis.  Well, there basically isn't any at the
> > moment -- d2c always inlines if the programmer tells it to, and never
> > inlines if the programmer doesn't tell it to.  Need to make a recursive
> > "cost" function that estimates a cost in codespace & time of inlining or
> > not inlining, including the effects of being able to eliminate GF calls in
> > the inlined function.  This will probably slow the compiler down a smidge,
> > so it needs to be optional, and also have "inline for speed" and "inline
> > for space" options.

Along those same lines....

 http://www.cs.washington.edu/research/projects/cecil/www/Papers/auto-...

[ of course it is a tad easier to do "partial evaluation" in Self. ;-) ]

---

Lyman



Mon, 21 Jan 2002 03:00:00 GMT  
 Two questions

Quote:

> Wow. I've just looked in src/d2c/runtime/dylan and am seriously
> impressed. Every piece of code I've looked at is SO clean. There's so
> little cruft that I'm comprehending most things on the first pass.

A lot of that comes down to it being written in Dylan, of course -- the
pervasive polymorphism, the clean iteration over any type of collection,
the functional programming aspects (map, reduce, curry etc).  Just all
makes it way, way cleaner to read than doing the same sort of thing in,
say, C++ with the STL.

And of course the original guys at CMU have done a great job to leave us
such a legacy.

Quote:
> Is there a todo list? I had just hoped to learn a little about how d2c
> worked, but now it looks like I might actually comprehend enough to
> make some useful contributions.

I just got email from Eric Kidd saying that the mailing list server is
back up but won't be visible for a little while.  I think that means it's
plugged in at a different site and has a new IP number and the DNS changes
need time to propogate.  Or it could be something else...

In the meantime, my own personal "TODO" list, as emailed to the other guys
a few days ago, is:

Quote:
> Other things on my "soon" list (by Xmas?) to look at:

> - add "no applicable method in foo for class <bar> in sealed domain.  Did
> you want one?" warning.  The place to put this seems to be in the method
> that generates the static discriminator function for the GF.  However
> static discriminator functions don't seem to be getting used as much as I
> think they should :-(

> - finish the limited vector stuff that I've already 80% done and get it
> out to you guys.  (Other limited collections can wait until vectors get
> shaken down in the field, I think...)  What I've done works
> beeeeautifully, including proper type inferencing of stuff that's pulled
> out using element() -- the compiler does *not* think that it's <object>
> like the element() GF says...

> - improve inlining analysis.  Well, there basically isn't any at the
> moment -- d2c always inlines if the programmer tells it to, and never
> inlines if the programmer doesn't tell it to.  Need to make a recursive
> "cost" function that estimates a cost in codespace & time of inlining or
> not inlining, including the effects of being able to eliminate GF calls in
> the inlined function.  This will probably slow the compiler down a smidge,
> so it needs to be optional, and also have "inline for speed" and "inline
> for space" options.

> - add automatic "outlining".  When a function is a good speed candidate
> for inlining (because of GF call elimination) but is a bad one because of
> space (i.e. its *BIG*) it can be a good idea to do the inlining
> optomisation but generate an actual function (and add it back into the GF)
> and call it from each place it's used instead of actually inlining it at
> the call site.  This gives all the benefits of C++'s "template functions",
> but without having to make a syntactically and semantically different
> thing.

> When all this is done, the compiler should be much faster, but it will
> still be big.  So the next thing:

> - add an option to generate code for the whole program (code, heap, used
> libraries) into a single huge C file and compile that.  That will let d2c
> remove lots of "extern" and the like on things.  And *that* will allow the
> underlying C compiler to do some smarter stuff, including noticing stuff
> that isn't used and leaving it out of the final program.

> - get d2c to do its own analysis of what is and isn't needed in the C
> code.  It pretty much already does this, but on a local basis rather than
> global.

> - the "inlining" and "outlining" stuff has the potential to *really* help
> here.  If all uses of a GF are inlined, comverted to known function calls
> or even (to a lesser extent) to calls for a static discriminator function
> for a subdomain, then the GF itself can be dropped like a hot potato(e)
> from the generated code.  No code, no heap data.  And then *that* lets you
> drop off all the methods in that GF that aren't otherwise used, and the
> ones *they* use and ...

> hmm.  Looks like I should copy this to the other guys in the absense of
> the list...

-- Bruce


Tue, 22 Jan 2002 03:00:00 GMT  
 Two questions

Quote:



...
> > [ of course it is a tad easier to do "partial evaluation" in Self. ;-) ]

> Why?  Dylan compilers are already doing a good bit of partial evaluation.

 Not so much inherit in the respective languages, but in the way they are
 typically implemented.  "Partial Evaluation" probably wasn't the best
 descriptor of what I was thinking.

 Self typically compiles things at "runtime".   There is always more
 specific type information at runtime.  You have to way the "JIT"
 overhead with the performance increase.  Self could always compile
 a good enough for the current context and when the context
 changed, trigger another recompile.  Just like profile feedback to
 the inliner would give enhanced value to an inlining heuristic (if
 a function isn't a "hot spot" there's no reason to inline it no matter
 what the programmer may think. :-) ).

 You can do Cooper-like stuff and split to enhance the static resolution,
 but there are often limits.

---
Lyman



Tue, 22 Jan 2002 03:00:00 GMT  
 Two questions

Quote:


> ....
> > > - improve inlining analysis.  Well, there basically isn't any at the
> > > moment -- d2c always inlines if the programmer tells it to, and never
> > > inlines if the programmer doesn't tell it to.  Need to make a recursive
> > > "cost" function that estimates a cost in codespace & time of inlining or
> > > not inlining, including the effects of being able to eliminate GF calls in
> > > the inlined function.  This will probably slow the compiler down a smidge,
> > > so it needs to be optional, and also have "inline for speed" and "inline
> > > for space" options.

> Along those same lines....

http://www.cs.washington.edu/research/projects/cecil/www/Papers/auto-...

Thanks for that.  An interesting paper, and doing pretty much exactly what
I was thinking about.  I suspect it's even more useful in Dylan, as there
is more often good type information available.

Another paper sounds even more interesting:

---------------------------------------
Cooper, Hall, and Kennedy present a technique for identifying when
creating multiple, specialized copies of a procedure can enable
optimizations [Cooper et al. 92]. They apply this algorithm to the
interprocedural constant propagation problem. To reduce the number of
specialized copies of a procedure, their system evaluates when merging two
specialized versions of a procedure would not sacrifice an important
optimization. Our type group guards on database entries accomplish a
similar task, enabling the results of an inlining trial to be reused for
those call sites where similar optimizations are enabled, but over a
richer domain of types.

[Cooper et al. 92] Keith D. Cooper, Mary W. Hall, and Ken Kennedy.
Procedure Cloning. In Proceeding of the 1992 IEEE International Conference
on Computer Languages, pp. 96-105, Oakland, CA, April, 1992.
---------------------------------------

There are limits after which actual inlining becomes silly and the direct
overhead of the function calls is insignificant and code bloat is a
happening thing.  But when you know exactly which function you will be
calling and its specialisers are more general than your known parameter
types, creating a more specialised version of the function can capture the
secondary benefits of inlining without the code bloat aspects -- provided
that the function is called from more than one site.

And if you add the generated function back into the Generic Function then
you can even get the benefit by accident, when you didn't know the types
at compile time but your specialised function gets sslected at runtime.
That could be a really big win.

I've been thinking about another type of criterion for inlining.  Whenever
in a class hierachy there are general purpose functions defined high in
the hierachy that are called by more specialised functions lower in the
hierachy, such a call loses type information which has to be rediscovered
later by type tests or a Generic Function dispatch.  In such a case, the
more general function should probably be inlined into the more specialised
caller, or at least a more specialised copy of it created, to preserve the
type information.

Quote:
> [ of course it is a tad easier to do "partial evaluation" in Self. ;-) ]

Why?  Dylan compilers are already doing a good bit of partial evaluation.

-- Bruce



Wed, 23 Jan 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Two questions regarding J's syntax and semantics

2. two questions RB & MacOs

3. Two Questions

4. Two Questions About Squeak

5. Two questions about Windows Applications

6. Two questions about default buttons...

7. Two questions

8. Two questions C5.0b

9. Two questions

10. Two Questions

11. Two questions about compiling/linking

12. Two Questions.

 

 
Powered by phpBB® Forum Software