Re: gEDA-user: How I'd write a netlister in Scheme... Was: Introduction and some questions/thoughts on gEDA/gaf...

[Dan McMahill <dan@xxxxxxxxxxxx>]

Karel Kulhavy wrote:
> On Sun, Sep 25, 2005 at 12:07:43PM -0400, Dan McMahill wrote:
>
> > Ales Hvezda wrote:
> >
> > > [snip]
> > >
> > >
> > > > 	For a while now, tinyscheme has been on my guile replacement list,
> > > > but it too, isn't really maintained anymore.  It isn't as full featured
> > > > as guile, but it seems to provide the bare basics.
> > >
> > >
> > > 	Another possibility is scheme 48:
> > >
> > > http://www.s48.org/
> > >
> > > 						-Ales
> >
> > That one has major problems on my alpha.  Produced lots and lots of 
> > unaligned accesses followed by a segfault on the alpha.  On i386 and 
> > sparc (in 32 bit mode), it built with one warning about 'comparison is 
> > always false due to limited range of data type' but was able to execute 
> > (* 3 4).
>
>
> Isn't 48 in the name of s48 the problem? Maybe you need s64 for alpha.
> 48 is not a multiple of 64.

since 48 is the number of hours taken to write the first version 
scheme48, maybe '48' is the problem ;)

Seriously though, I think the moral of the story is that the development 
of a compiler or even a scheme interpreter that has wide cross platform 
support is not as trivial as one might think.  Just in case anyone 
thinks I'm being silly about viewing alpha as an important processor, 
the main point is that code which fails to compile and run on the alpha 
has been a pretty good indicator in the past for me that there are many 
underlying bugs.  It is amazing how many times I see functions which 
return pointers fail to have prototypes.  Bad because default return 
type is an int which isn't big enough for a pointer on an alpha.  Other 
times I come across people simply using ints intentionally to hold 
pointers, again, it is just a matter of time until that fails on some 
platform.  Some other favorite tricks I've come across are things like:

#ifndef __m68k__
#define LITTLE_ENDIAN
#else
#define BIG_ENDIAN
#endif

oops.  forgot sparc, mipseb, armeb, ppc.

And with the whole unaligned access, it is an indicator of someone 
abusing pointer typecasts.  I've seen code which had no chance of 
working correctly on a sparc because of assumptions about byte alignment 
in a struct.  Another place where C allowed sloppy code to work on i386, 
but not be portable.

I'm sure the darwin folks have had their share of headaches with code 
which is sloppy with endianness and as more users start using x86_64, 
the 64 bit bugs which have plagued us alpha users for years will bite 
them too.  As for the poor sparc64 users, well, its amazing sometimes 
when any code works there!

-Dan