main and Re: C strings and other things!

[Lars Hupfeldt Nielsen]

Hi again Keith,

I am planning to port our application from Java to Sather during Christmas to 
see
what performance gain we will get.
However in 1.2 there were a couple of significant practical problems:

1) The 'main' routine had to be in Sather.
Our application is a Tcl extension, meaning it consists of a bunch of procedures
which are called by Tcl, 'main' is out of my reach.
You have previously spoken about Sather libraries, which would need to allow
compilation without specifying a main routine, is this something you have been
working on?

2) You could not link with a shared library (the .so and other extensions was 
not
recognized)
I patched the 1.2 compiler to allow linking with a shared library, however I 
am, not
sure that this is correct with regard to the garbage collector. Does the gc 
need to
know about the library if the library uses heap? I guess that this is probably 
very
platform dependent?

3) Executables were huge!
Has the size gone down?

Keith, did you ever get around to reading the Sather-K specification? Sather-K 
has
some nice features which should be considered for the next revision. Once there 
was
an effort to merge the two diverging specifications. You need more manpower, so 
it
might be an idea to try to re-start the cooperation with Karlsruhe.

Now to your latest mail:

Keith Hopper wrote:

> In article <address@hidden>,
>    Norbert Nemec <address@hidden> wrote:
> > On Wed, Dec 13, 2000 at 01:37:37AM +0000, Dave Simons wrote:
> > > Please, PLEASE, Sathermasters, integrate something into the STR class
> > > to give this speed legally, cleanly, and portably!

Yes, unfortunately the world was written in C, so it must be made extremely 
easy to
integrate with C code.
As far as I remember, in the old STR class there was no method converting an 
STR to
a C_CHAR_PTR, but handing an STR to a function taking a '\0' terminated char[] 
would
work. This was very ugly. May I suggest something like STR.byte_str_z?

> Change of Subject
> -----------------
>      In the course of some of the formal specification work which I am
> trying to get to grips with I have come across a number of anomalies which
> give me cause for concern -- anyone who feels able to comment
> constructively on the following will be welcomed with open arms (or
> something!!) -
>
>      (1)  I am slowly coming to the conclusion that there is a need for a
> class we may call ORD (short for ordinal) which has two operations - succ
> and pred (or some such name) with a couple of predicates/values, etc) and
> is the only class to contain the times! iter (both variants) and possibly
> an 'up!' and upto! variant - and is the class used when indexing containers
> of all sorts.  My reasoning comes from the general specification of all
> iters  which technically need a history trace (in order to specify them)
> for which the empty value is the only value on initial invcation - all
> further history is a counted sequence.  This may seem an unnecessary
> additional library class, but it will certainly simplify a lot of checking
> code generation.  You will certainly realise that the current vogue for
> indexing containers starting with zero is conventionally used where a
> pointer to a memory location and an offset from that of zero is the first
> element in the container.  Since Sather does not have pointers (well even
> Pascal provided for arbitrary array indexing) there seems little reason to
> perpetuate the use of zero at programmer level (how a compiler implementer
> goes about twiddling bits and bytes to do the right thing is only of
> concern to them).  Theoretically I thnk that it is the correct thing to do,
> as it does making container indices what they are ordinal numbers referring
> to the first, second, etc elements - Introducing this will, however,
> introduce the possibility of 'off by one' errors in existing code - only a
> one off revision, I must hasten to stress - and then a significant saving
> in code generated when indexing and limit checking.

I don't really get it. When indexing array elements directly, how are iterators
involved?
Are you suggesting that array bounds can be freely specified as in Pascal, or 
that
they start from 1? Specification of lower bound is a neat feature but 
definitely not
a significant one, and not one for which I personally would like to trade in any
performance. To have arrays start from 1 which is more intuitive (at least to 
new
programmers) than having them start from 0, but again I think not significant 
enough
to give up much performance (performance counts in the real world:) . Maybe you
could post the (pre) ORD class, often an example helps understanding.

Unfortunately I have not programmed enough in Sather to really comment on the
library.


> While I could 'go public' with a partially
> fixed version before Christmas, I would prefer to talk about the end of
> February (I am away for six weeks in China just after Christmas).

Please do make a release before Christmas, as long as it is progress from the 
last
release. How is the new runtime coming along?

I might have a look at the 'main in Sather' problem during Christmas. Is it
worthwile for me to look at the distributed sources or are you workig on a
completely new compiler?

Merry Christmas everybody

Regards,

Lars hupfeldt