Implementation Language

Implementation Language

[Doug Evans]

Ben Elliston writes:
 > We've been running CGEN purely interpeted for several months now and no one
 > is finding the speed to be a problem at all.

The smob class implementation is gone too though.
Debugging was much easier with it.
[Of course, for those tuning in late, should the implementation
remain in Guile, yes, we'll want to switch to goops (IMO of course).]

That's probably the first decision we need to reach:
do we stick with Guile?  There's no other politically correct
choice for a Scheme implementation. Or do we switch to C? (/C++?).
[I can here the cackles now ...]

I think speed of code generation is important, but I also think
there's no reason why a Scheme implementation can't satisfy that.
However, I think the current Guile implementation has a _long_ way to go
in this regard, and I'm not convinced it will ever get there.

Re: Implementation Language

[Frank Ch. Eigler]

Hi -

On Sat, Jul 29, 2000 at 09:25:26AM -0700, Doug Evans wrote:
> [...]
> That's probably the first decision we need to reach:
> do we stick with Guile?  

I would like to keep Scheme, especially if some of the code
is reorganized.  The halfhearted O-O structures (not cos.scm,
but its uses) particularly bug me.

> There's no other politically correct
> choice for a Scheme implementation.

We don't need to be dependent on any particular Scheme
implementation.  We could assume R5RS, and add only
essential minimal interpreter-specifics.

> [...]
> However, I think the current Guile implementation has a _long_ way to go
> in this regard, and I'm not convinced it will ever get there.

It's a good operational starting point.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE5hihXVZbdDOm/ZT0RASjFAJ90pEcERwusDsYZzMpymrgJtibAaACXd5Wm
kVLatHWLALK5LuFAGfih4g==
=zsmJ
-----END PGP SIGNATURE-----

Re: Implementation Language

[Ben Elliston]

   I would like to keep Scheme, especially if some of the code is
   reorganized.  The halfhearted O-O structures (not cos.scm, but its
   uses) particularly bug me.

Likewise.  R5RS has no object system, right?  Is GOOPS a risky proposition?

   We don't need to be dependent on any particular Scheme implementation.  
   We could assume R5RS, and add only essential minimal
   interpreter-specifics.

I'm all for this.

   > However, I think the current Guile implementation has a _long_ way to go
   > in this regard, and I'm not convinced it will ever get there.
   
   It's a good operational starting point.

Is it likely that we can have any influence over the Guile crowd to get the
things from Guile that we want?  What's wrong exactly with the Guile
implementation--if considered as simply an implementation of R5RS?

Ben

Re: Implementation Language

[Frank Ch. Eigler]

Hi -

bje wrote:
>    I would like to keep Scheme, especially if some of the code is
>    reorganized.  The halfhearted O-O structures (not cos.scm, but its
>    uses) particularly bug me.
> 
> Likewise.  R5RS has no object system, right?  

That's right.

> Is GOOPS a risky proposition?

Well, a little, since it's not purely implemented in Scheme, but partly
in C, and is therefore not portable elsewhere.  Other Scheme OO packages
are pure Scheme (but probably perform less well, or whatever).  I would
not mind adopting a different pure-Scheme OO package, or even tightening
up Doug's current `cos.scm'.

But before any of that, we should sketch out a more ideal object hierarchy
for all the various little devilish types currently used in cgen.


> [...] What's wrong exactly with the Guile implementation--if considered
> as simply an implementation of R5RS?

Nothing big AFAIK --- it's just tempting to depend on its extensions rather
than using standard libraries like SLIB.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5iLh9VZbdDOm/ZT0RAcmVAJ9wrrfFflcK+OCJ+kmRu43MaX/XrACeLynu
56kJExjP282R+GAbjFzER0U=
=+Qas
-----END PGP SIGNATURE-----

Re: Implementation Language

[Ben Elliston]

   > [...] What's wrong exactly with the Guile implementation--if considered
   > as simply an implementation of R5RS?
   
   Nothing big AFAIK --- it's just tempting to depend on its extensions rather
   than using standard libraries like SLIB.

I think it's simple: we need to resist such temptations and write in
portable Scheme.  Do we have any performance issues with Guile?  

Personally, I'd like to see us keep it and refine what we have.  As we know,
rewrites are rarely a panacea. :-)

Ben

re: Implementation Language

[matthew green]

for what my opinion is worth, i like the fact that cgen is written in scheme.


i also pretty much concur with what others have said beyond this point.

Re: Implementation Language

[Doug Evans]

Ben Elliston writes:
 >    > [...] What's wrong exactly with the Guile implementation--if considered
 >    > as simply an implementation of R5RS?
 >    
 >    Nothing big AFAIK --- it's just tempting to depend on its extensions rather
 >    than using standard libraries like SLIB.
 > 
 > I think it's simple: we need to resist such temptations and write in
 > portable Scheme.

Modulo: we can write in C those parts we wish to
as long as a portable Scheme version also exists [e.g. cos.c,
not that I necessarily want to keep it in the long run,
but rather as an example of what I mean here.]

 > Do we have any performance issues with Guile?  

Yes!!!

 > Personally, I'd like to see us keep it and refine what we have.  As we know,
 > rewrites are rarely a panacea. :-)

But they're fun. :-)
And after we have at least one more big usage under our belt
[dynamic compilation?] and we have a proper function unit description
[plus related paraphenalia] I think we should take a step back
and review everything from the ground up.

Re: Implementation Language

[Doug Evans]

Doug Evans writes:
 > But they're fun. :-)
 > And after we have at least one more big usage under our belt
 > [dynamic compilation?] and we have a proper function unit description
 > [plus related paraphenalia] I think we should take a step back
 > and review everything from the ground up.

Oh ya, I also want to finish up the `insn frame' section
of define-isa. [I'm sure there's more, I'll mention them
as I think of them.]

Re: Implementation Language

[Ben Elliston]

   Oh ya, I also want to finish up the `insn frame' section of
   define-isa. [I'm sure there's more, I'll mention them as I think of
   them.]

What's that?   

Ben

Re: Implementation Language

[Doug Evans]

Ben Elliston writes:
 >    Oh ya, I also want to finish up the `insn frame' section of
 >    define-isa. [I'm sure there's more, I'll mention them as I think of
 >    them.]
 > 
 > What's that?   

Grep for `frame' in m32r.cpu.
What's there now is just to get some thoughts down on paper
and begin a prototype.

Re: Implementation Language

[Ben Elliston]

   Modulo: we can write in C those parts we wish to as long as a portable
   Scheme version also exists [e.g. cos.c, not that I necessarily want to
   keep it in the long run, but rather as an example of what I mean
   here.]

So does Guile follow a similar philosophy to Tcl -- to write performance
critical aspects in C and provide hooks into Scheme?
   
    > Do we have any performance issues with Guile?  
   Yes!!!

Can you expand?  I don't really consider the performance of code generation
to be that critical -- look at G++ these days.

   But they're fun. :-)

I envy your energy, Doug.

   And after we have at least one more big usage under our belt [dynamic
   compilation?] and we have a proper function unit description [plus
   related paraphenalia] I think we should take a step back and review
   everything from the ground up.

Sounds reasonable.  Post-evaluation is an important exercise.

Ben

Re: Implementation Language

[Doug Evans]

Ben Elliston writes:
 > So does Guile follow a similar philosophy to Tcl -- to write performance
 > critical aspects in C and provide hooks into Scheme?

Dunno in general, but that's certainly not excluded.  The hooks are
there, it's up to each app to use them or not.

 >     > Do we have any performance issues with Guile?  
 >    Yes!!!
 > 
 > Can you expand?  I don't really consider the performance of code generation
 > to be that critical -- look at G++ these days.

Also look at how long cgen takes to run vs the gen* fns in gcc.
I don't mind the wait (much), but for the general audience I think
that there's an order of magnitude speed up to be had
and one way or another, I think it'll be thrust upon us.
I'd rather the end result still be Scheme.
[The Guile powers-that-be now believe (I think) that the current
implementation isn't the best way to go and someone is writing
a faster engine.  Dunno how much of a speed up we'll get.]

btw, I'm playing with Rscheme a lot these days.
http://www.rscheme.org
This is a Scheme implementation that rocks! (IMO)
Speed-wise I think it also has a way to go, but
the internals and design appeal to my aesthetic tastes (ymmv)
in a way that Guile probably never will.

Re: Implementation Language

[Frank Ch. Eigler]

Hi -

dje wrote:

>  > Can you expand?  I don't really consider the performance of code generation
>  > to be that critical -- look at G++ these days.
> 
> Also look at how long cgen takes to run vs the gen* fns in gcc. [...]

Right, though continuing to keep generated files cached
in CVS at least limits the pain to active developers
instead of everyone.


> btw, I'm playing with Rscheme a lot these days.  [...]

Looks nice, but them nonstandard extensions sure look addictive.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5jd4hVZbdDOm/ZT0RAYeGAJ4501afmc/aM1XQKD6O5BzQMLJ0AQCfYvrc
lWW5l1DyBsq4NXrBgvZ6UoA=
=HCrF
-----END PGP SIGNATURE-----

Re: Implementation Language

[Ben Elliston]

   Right, though continuing to keep generated files cached in CVS at
   least limits the pain to active developers instead of everyone.

True.

   > btw, I'm playing with Rscheme a lot these days.  [...]
   
   Looks nice, but them nonstandard extensions sure look addictive.

Can someone provide some references to Rscheme on the Web?

Ben

Re: Implementation Language

[Doug Evans]

Frank Ch. Eigler writes:
 > > btw, I'm playing with Rscheme a lot these days.  [...]
 > 
 > Looks nice, but them nonstandard extensions sure look addictive.

So are computed gotos yet people manage to use them portably ...