This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
telford@eng.uts.edu.au writes: > > My principles say that you shouldn't do something wrong yourself in an > attempt to compensate for someone else doing the wrong thing -- you should > do the right thing and encourage other folks to do so too. > That's nice in theory, but in practice it would that any non-trivial code meant to be protable on Unixoid operating systems would not run on _any_, since they are all broken one way or another (yes, even Linux and *BSD). > I feel that Hobbit's job is to translate nicely expressed scheme code > into nicely expressed C code. If a tail call in scheme is optimisable > to a jump then Hobbit should try to find an equivalent C tail call that > is also optimisable to a jump -- because that is basically the nicest > way to express the equivalent concept in the C language. > IMO Hobbit's output should be portable to as many C compilers as possible while remaining as RnRS compliant as possible. Saying "wait for every C compiler to optimize tail calls" is not a solution. > Whether the C compiler picks up all available optimisations is quite a > separate issue but as far as RESPONSIBILITY goes, Hobbit should try to > overlap the C compiler as little as possible. > C compilers can not be relied upon to optimize tail calls (in fact, it may be undesirable in some ways, and impossible under some ABIs) - the C standard does not require this. But the Scheme standard does require this. So this property must be guaranteed without relying on C compiler features beyond the standard. If I were coding a compiler from C to Intel machine language, and Intel machine language did not have some semantics that C might need, I wouldn't wait for Intel's engineers to "do the right thing." A compiler from language X to C should just treat C as portable assembly language. It's a compiler, not a translator. > > One further point is that Hobbit's output should be as readable as possible > and trying to build optimisations into the C code is guaranteed to produce > unreadable code. Yes, you should give the C compiler every chance by setting > things up in a way that encourages optimisation but no you shouldn't make > a messy hack. > I'm not sure it was ever a goal of Hobbit to emit readable code. - Maciej