Subject: [clisp-list] avcall-i386.c

From: Peter Wood <[email-masked]>
Date: Tue Apr 9 07:23:30 2002

Hi,

Why is the file ffcall/avcall/avcall-i386.c not used?  I've compiled
with it and it (seemingly) works fine (Gnu/Linux x86).  Why does Clisp
do the hairy cpp|grep|sed x.S -> x.s thing??

Regards,
Peter

---

From: Sam Steingold <[email-masked]>
Date: Tue Apr 9 10:30:37 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] avcall-i386.c"
> * Sent on Tue, 9 Apr 2002 16:03:35 +0200
> * Honorable Peter Wood <[email-masked]> writes:
>

performance?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Never trust a man who can count to 1024 on his fingers.

---

From: Will Newton <[email-masked]>
Date: Tue Apr 9 11:29:06 2002

> do the hairy cpp|grep|sed x.S -> x.s thing??

In an attempt to work on a wide array of broken compilers and assemblers most 
probably. It really is a bit of a mess in there, but I am definitely not 
volunteering to clean it up. :)
It's one of those "change one line, then check it builds on 30 different 
architectures" jobs.

---

From: Peter Wood <[email-masked]>
Date: Tue Apr 9 11:33:35 2002

Hi,

> > do the hairy cpp|grep|sed x.S -> x.s thing??

I bet it's impossible to meaningfully measure the performance
difference of this little drop of code in Clisp's ocean.  Maybe you
gain a few machine instructions.

So compare instead the added simplicity in the build process (which is
achieved by allowing gcc to compile the 'straight' .c file) with the
hairy, scary sed cruft.

On the other hand, maybe there's some other reason as well ...

Regards,
Peter

---

From: Peter Wood <[email-masked]>
Date: Tue Apr 9 13:06:06 2002

Hi,

> It's one of those "change one line, then check it builds on 30 different 

This is definitely true, but the Makefile already deals with the '30
architectures' and I am only (tentatively) suggesting that the rule
for avcall-i386.lo be changed, not the rules for sparc, mips, m68k,
etc:

avcall-i386.lo : $(srcdir)/avcall-i386.c
        $(LIBTOOL_COMPILE) $(CC) $(CFLAGS) -c $(srcdir)/avcall-i386.c

(instead of)

#avcall-i386.lo : avcall-i386.s
#       $(LIBTOOL_COMPILE) $(CC) -x none -c avcall-i386.s
#
#avcall-i386.s : $(srcdir)/avcall-i386-macro.S
#       $(CPP) $(ASPFLAGS) $(srcdir)/avcall-i386-macro.S | grep -v '^ *#line' | 
grep -v '^#ident' | grep -v '^#' | sed -e 's,% ,%,g' -e 's,% ,%,g' -e 's,\. ,.,g
' > avcall-i386.s

So we wouldn't have to worry about the 30 architectures, 'just' the
few os's that run on i386, apart from linux which seems fine.

Another advantage to using the .c file is you can follow Clisp into
avcall on gdb - well, you can do it with the .s file too, but
assembler is ... assembler.

I don't suppose it really matters, and there _may_ be something wrong
with compiling with the c file that I don't know about.

Regards,
Peter

---

From: Will Newton <[email-masked]>
Date: Tue Apr 9 14:33:05 2002

> for avcall-i386.lo be changed, not the rules for sparc, mips, m68k,

Fair enough, if you are willing to take on the repsonsibility of working this 
out I'm sure a patch would be accepted.

> #       $(CPP) $(ASPFLAGS) $(srcdir)/avcall-i386-macro.S | grep -v '^
> *#line' | grep -v '^#ident' | grep -v '^#' | sed -e 's,% ,%,g' -e 's,%
> ,%,g' -e 's,\. ,.,g ' > avcall-i386.s

First we have to figure out what this does. AFAIK at the moment it does very 
little. I think it is possible to remove this without any harm. I would like 
someone who knew a little more about the code (Bruno?) to comment on this, 
but I would guess it was written for some older code.

> assembler is ... assembler.

It's not really that much assembler.

> with compiling with the c file that I don't know about.

It is necessary to get the CFLAGS correct - the hppa code I have just written 
requires no optimization be applied to it. I imagine one of the reasons the 
assembler files are shipped with avcall is that the things that are being 
done tend to test the optimizer of the compiler to the limit.

---

From: Peter Burwood <[email-masked]>
Date: Tue Apr 16 13:04:22 2002

Hi,

I can provide some insight into this, though it is from hazy memory and I
reserve the right to be slightly wrong.

> out I'm sure a patch would be accepted.

I really cannot see the advantage of this proposed change. The code works as
is and if you use the .c version, you might inadvertently break another i386
based platform.

> but I would guess it was written for some older code.

It ensures that the .s file produced can be processed by the assembler. It
does this by removing lines inserted by the CPP process that would upset the
assembler. It also removes some spaces introduced by the CPP process, again
because the assembler wouldn't grok the file otherwise.

Trust me when I say Bruno would not put something horrible like that in
unless there was a very good reason. Ok, I realise that the world has moved
on since Bruno wrote Clisp and somethings may be unnecessary now, but Clisp
has a reputation for the number of platforms it runs on and runs on
correctly. It got that reputation by Bruno not trusting certain things and
being a little paranoid. Please don't go removing something you don't
understand just because it seems unnecessary on your platform.

> It's not really that much assembler.

I agree. If you really want to be able to follow Clisp into avcall with gdb,
then I would suggest you make a special debug version that uses the .c
version rather than risking break avcall for other people. I'm sure you will
be able to count the number of people that want to do that on one hand,
maybe even one finger.

> > with compiling with the c file that I don't know about.

The .S are used instead of .c files because we are hacking around at a
fairly low level and there is no guarantee that the compiler will produce
the right code. Even if the compiler can do it today, there is no guarantee
it won't break in the future. Compilers tend to have far more bugs than
assemblers.

Also, avcall-i386.c even has in its comments
   "For other compilers [non gcc] use the pre-compiled assembler version."

This is quite important, e.g., for Solaris CC on i386 or lcc on Windows
i386, etc, the .c file will probably not produce assembly code that will do
the right thing.

> requires no optimization be applied to it.

Are you saying that using optimization on HPPA makes avcall not work?

It is certainly true that the optimizer could remove or reorder some code,
which would be a bit of a show stopper.

> I imagine one of the reasons the assembler files are shipped with avcall
> is that the things that are being done tend to test the optimizer of the
> compiler to the limit.

I would say thay 'optimization' of the code for performance is secondary.
Getting the code to do the right thing in this hairy area is primary.

regards,
Peter

---

From: Peter Wood <[email-masked]>
Date: Wed Apr 17 06:33:03 2002

Hi,

On Tue, Apr 16, 2002 at 06:47:23PM +0100, Peter Burwood wrote:
 
> being a little paranoid.

First of all, let me say that I don't particularly care one way or the
other.  If something got my goat enough, I could just go my own way.

Having said that, I have the following remarks:

1) In principle, I dislike appeals to authority.  Noone is
infallible.  Certainly, noone is infallible _forever_.

2) Your approach is overly cautious.  In 20 years, if we never remove
unnecessary code, never consolidate, never rationalise, or clean-up
generally, we are going to have one crufty, hairy ball of cr*p.  In
fact, we might even have CMUCL.

> Please don't go removing something you don't

3) I could as easily say "please don't retain something you don't
understand just because you fear it may be necessary on your platform."

I am not suggesting that we obliterate and remove from history the
assembler files; if we tried it with the c files, and gcc couldn't
handle it on platform xyz, then we could just put the necessary file
back.  Clisp's reputation is strong enough to weather a little thing
like that.  Most users wouldn't even know.

4) According to sourceforge cvs, a lot of the .s files are simply
generated by gcc.

Your way, ... we'll never know.

Regards,
Peter

---

From: Sam Steingold <[email-masked]>
Date: Wed Apr 17 10:27:01 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] avcall-i386.c"
> * Sent on Wed, 17 Apr 2002 15:18:32 +0200

sure.

> generally, we are going to have one crufty, hairy ball of cr*p.  

absolutely 

> In fact, we might even have CMUCL.
what is wrong with CMUCL?
I thought it was great!

> understand just because you fear it may be necessary on your platform."

like RMS did with VAX support in ange-ftp?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
There are 3 kinds of people: those who can count and those who cannot.

---

From: Raymond Toy <[email-masked]>
Date: Wed Apr 17 11:56:12 2002

>>>>> "Peter" == Peter Wood <[email-masked]> writes:

    Peter> 2) Your approach is overly cautious.  In 20 years, if we never remove
    Peter> unnecessary code, never consolidate, never rationalise, or clean-up
    Peter> generally, we are going to have one crufty, hairy ball of cr*p.  In
    Peter> fact, we might even have CMUCL.

Are you saying CMUCL is cr*p?  If so, why?

Ray

---

From: Peter Wood <[email-masked]>
Date: Wed Apr 17 13:18:15 2002

Hi,
> Are you saying CMUCL is cr*p?  If so, why?

No.  CMUCL is great in many ways.  However I think the CMUCL build
process _is_ crap.  This discussion is about retaining/discarding
(possibly) unneeded files from Clisp.  I tried to generalise about the
need to rationalise and consolidate.  

The point I was making with the comparison was that IMO, that need
went unfulfilled for many years (_specifically_ regarding the build
process) in CMUCL development, and it 'ended' with a fork.

I don't like the approach that "if it isn't actually breaking
something NOW, then leave it alone".  Over time it results in a mess.
People forget what things are for, or move on.  New people come along
and regard the stuff they inherit with superstitious awe.  Its not
healthy.

I did not intend to offend you, or other CMUCL users, nor am I
suggesting that there are unnecessary files in CMUCL's build, but that
CMUCL's build process is/has become absurdly complex and
convoluted. (ie, hairy, crufty, crappy)

Regards,
Peter

---

From: Peter Burwood <[email-masked]>
Date: Wed Apr 17 15:02:11 2002

Hi,

> other.  If something got my goat enough, I could just go my own way.

Fine.

> infallible.  Certainly, noone is infallible _forever_.

Absolutely, I never said otherwise.  I didn't mean to suggest Bruno is
infallible, I know he isn't. It'd be nice if software was though!

> 2) Your approach is overly cautious.

Probably.

> In 20 years, if we never remove

I agree, but I didn't say don't remove anything.  I explained why the .S
files exist and gave a reason for their continued existence.  Please don't
change my words.  I said you shouldn't remove something just because you
don't understand it, not that nothing should ever be removed.  As it
happens, you've followed this general rule, because you are asking why Clisp
has these apparent duplicate files.

But you're right, we should clean up the avcall-i386 stuff and remove
something. How about the .c file?

Ah but, the .c files do serve a purpose.  They help porting to a new
platform with the same CPU but different calling convention, or to an
unsupported CPU, because you can run the .c file through the compiler to get
the first pass at a working avcall.

So we'd better keep them.

> understand just because you fear it may be necessary on your platform."

That's not the same at all.  Your hypothesis is easy to prove one way or
another, mine is not.

> 4) According to sourceforge cvs, a lot of the .s files are simply

Sorry, but because I was just giving a bit of history from my hazy memory, I
forgot to check whether things had changed, or maybe my recollection was
wrong.  I had missed this fact.

But, as I said in my previous email, the .S files allow Clisp to be built
using a compiler other than gcc.

Thus, it seems both .c and .S are necessary, though for any one platform,
only one of them is needed.  If one thought it important, then the
avcall/Makefile could be generated to use the .c if the build compiler was
gcc.

> Your way, ... we'll never know.

You have misunderstood my email. I'm not a luddite against change. I welcome
change and improvement, where there is benefit.  It is certainly true that
the Clisp source has a fair amount of things that could be removed or are
implemented in an odd fashion, e.g.,

  . why have .d files?
  . why is so much Lisp written in C?

Anyway, hopefully I have explained why the .S files exist and are part of
the source distribution, so I'll leave it there.

cheers,
Peter

---

From: Peter Wood <[email-masked]>
Date: Sat Apr 20 23:16:02 2002

Hi,

> what is wrong with CMUCL?

You no longer do?

Regards,
Peter