Dear friends,
sorry it took so long for me to reply. I am not having a single bit
of peace these last days, but I'm reading all your mail...
Now, I'll try to reply in the best detail I can. Sorry if all topics
are accumulated right now, I'll try to be as clear as possible.
Before that, I'd like to thank Ed and Ralph for all their work and
advice which are being really useful in this matter. And of course,
I thank Dave for his participation in the discussion. Another thing
I'm sorry about is that this one will be long.
Ok, on with the work.
On Fri, 30 Oct 1998, Ed Hall wrote:
> It would perhaps be better if I reversed the order of your questions:
>
> > 2) what are the size of all natural types on an Alpha?
> >
>
> This table is for GCC (all versions I know about, including EGCS):
>
> type | sizeof(type) | NOTES
> ------------|-------------------------------------------------------------
> -
> char | 1
> short | 2
> int | 4 <<<<<<<< funny this is'nt 8: does'nt C state that int
is the natural type of the machine?
[snip]
> Both of the above issues are solved by changing all longs to ints. The
> remaining issues are small enough to be handled with a handful of patches.
> For example, around line 115 in oload.c there is a statement that determines
> the amount of memory that a given instrument will allocate for local
> storage. It is:
>
> ip->localen = (ip->lclfixed + ip->lclacnt*ksmps) * sizeof(float);
>
> To insure that 64-bit alignment is preserved on an alpha, we have to
> round up to 2*sizeof(float):
>
> ip->localen = ((ip->lclfixed + ip->lclacnt*ksmps + 1) & ~0x1) * sizeof(float);
I am surprised and upset that gcc does'nt do these kind of things
by itself, but what the hell, maybe it's a growth problem.
If it was possible to genereralize it, it would be nice to make a
little macro, something like ALIGN(addr,type) that does this bit, to
document it really well and put it somewhere in new-src (like
new-src/align.h). The idea is that I think it's going to take time to
weed out all the places and such a macro could come in handy in the
future, plus we might need to redefine it for other systems in the
future.
[snip]
On Fri, 30 Oct 1998, Ralf W. Stephan wrote:
[snip]
> Don't reinvent the wheel, just check how others do it, e.g.
> in gtk or even in my yarec (see home page) configure.in there
> are lines like
yes ralf, of course we don't plan at all to reinvet the wheel, and
the autoconf bit you quote will be very useful because it gives us
a good guide. But as Ed states later on, the problem is:
[snip]
> You can now typedef as you like in your headers:
>
> typedef unsigned char u8;
> #if SIZEOF_UNSIGNED_SHORT == 2
> typedef unsigned short u16;
> #else
> #if SIZEOF_UNSIGNED_INT == 2
> typedef unsigned int u16;
> #endif
> #endif
> #if SIZEOF_UNSIGNED_INT == 4
> typedef unsigned int u32;
> typedef int s32;
> #else
> #if SIZEOF_UNSIGNED_LONG == 4
> typedef unsigned long u32;
> typedef long s32;
> #endif
> #endif
>
> People have to learn to stand on the shoulders of others.
Yes, but then we have also to replace all the occurrences all over the
code. Then, when a new canonical release comes out, we will have to do
it again, then again, etc. *This* is the problem we are having at hand
currently, and that's where the wrapper solution comes in handy.
[snip]
On Fri, 30 Oct 1998, Ralf W. Stephan wrote:
[snip]
> This means that the canonical sources are less portable than
> the Linux ones which I understand to use automake/autoconf
> at some time. Hmnn, maybe I should install cvs on my system
> to help Nicola out there. Can take some time, since this is
> my first attempt...
you're welcome, and if there's anything I can do to help, don't hesitate
to ask. Are you using an alpha for testing?
[snip]
> > TODO: The wrapper should be enabled as part of the "configure" process.
>
> I'm not sure if your wrapper is the right thing [TM] since this
> obviously is solvable without it. Can't the maintainers of the
> canonical sources be convinced of using autoconf/automake?
> Other platforms would certainly benefit from it.
I'm not sure we can immediately solve this without it (because of the above
problems). I don't like the wrapper solution too (don't take it personally
Ed), but I agree with Ed that this is the most pragmatic solution right now,
plus autoconf already use wrappers like this for several tasks (install-sh,
etc.), so I would not make a scandal to add another one which gets used
in the alpha case. Concerning the maintainers of the canonical sources,
no, they don't use autoconf/automake and I do not have any information
that they plan to in the near future (you can always ask them). We built
the unix (really linux) development group in order to be able to use
the best tools we have at hand in the best way we know how to use them.
[snip]
> > Oh, and a question: is there a canonical list of orc/sco files that folks
> > are using for testing? I've been using my own plus some others picked
> > up around the net, but this isn't a full workout, especially of the newer
> > opcodes.
>
> That would be nice. BTW, the shaker gives me a SIGFPE.
I have proposed several times to make a directory (like doc/testsuite/problems
or something like that) and I am ready to build one in the near future
if we all agree on it. The point is that it is difficult to build a pervasive
test suite but we could start gathering together all orc/sco pairs that
create (or used to create) problems. I already have a few of these for
testing (what used to be) several problems (like diskin, comments, midifile
reading, float rounding, etc.). Ralf, if you would like to contribute
an orc/sco pair which creates the SIGFPE on shaker you would be most
welcome. Please advise on this, and let's start collecting these: then
we'll start thinking of a real test suite which should really stress
the system and find hidden problems (I'm thinking of serious numerical
testings etc.). I usually run all my orc/sco pairs after a new build to
verify that old problems did not crop up again and these orc/scos are
really useful.
[snip]
> Indeed. My objective has been to minimize the effort needed to port the
> canonical source--I actually started using the Linux ones rather late.
> My assumption has been that changes as extensive as Alpha requires aren't
> going to get back into JPff's sources any time soon.
Yes. Please let's not forget that:
a) csound is being used in dos/win95/NT/mac platforms too, and that the
canonical development deals mainly with general portability problems
b) people in the Win95/mac world do their own specific extensions to the
code and make separate distributions without worrying too much about
general cross-platform portability; this is correct, and it allows them
to progress faster
c) if/when code is at all portable, we can ask (as we have done for the
maldonado opcodes) the source directely to the author - my experience
is that the code is in better shape and more complete when coming
directly from the author; we can port it more quickly and any of
us can propose additions when she/he feels that it is worthwile
d) when we started this group we were all linuxers (maybe we still are,
in fact); we called it csound unix development because Robin (Whittle)
asked to be open to other unices, since it easy to do that with
autoconf - while I second this proposal, I feel the vast majority
of this group is using linux anyway, so we should work hard at making
this version of csound the best possible on linux
[snip]
> I agree, it isn't the Right Thing(tm). I'd argue that it's the most
> pragmatic thing, given the assumption that the Right Thing(tm) isn't
> practical at the moment.
I whole-heartedly agree.
>
> Here is how I'd like to do it, assuming that the changes got back to the
> canonical source:
>
> 1) Use autoconf to determine size, alignment, and byte-order.
> 2) Create a cstype.h file that typedef's a set of known-sized types, signed
> and unsigned. In earlier porting work I've used int8, uint8, int16, uint16,
> int32, uint32, int64, uint64, and size_t (many systems already define the
> latter). Other names can be used, of course (some folks might add _t or
> use capital letters or whatever).
this could go in new-src and then be included by cs.h just as config.h
is done. In fact, it could be included in config.h. I agree on the rest.
[snip]
> Comments? How likely do you think it would be that something like this
> could be done and made part of Canonical Csound?
Comments:
1) While merging the canonical source in the distribution, I have accumulated
(and I still do) a number of notes on <<how to do it>> because I tend
to forget things and it could be useful for others in the future;
it's a file called (unappropriately, I admit) README.NO_LINUX_UPDATE;
I would be grateful to you if you read it to get the jist of how the
merging is currently working (proposals are of course welcome); at any
rate, there are some files listed in there which I don't merge any more
because we made so many changes that there is no point in doing that
(they are just waiting for The Big Rewrite...)
2) If we all agree, within a couple of days I feel I or anybody else should
write to the csound list and in particular to its maintainer (jpff)
and propose a set of changes and possibly a diff file to apply to
the distribution; these patches should restrict themselves to type
name changes (already a big task, IMHO);
3) if we obtain this in some sort (my experience is that jpff likes to
'interpret' changes), then all the rest is easy; if we don't obtain
it we'll keep the changes for the Big Rewrite, whenever that will
happen.
[snip]
On Sat, 31 Oct 1998, Ralf W. Stephan wrote:
[snip]
> This is the main problem: the canonical sources would have to
> be changed every time. But maybe this can be solved by using
> typedef plus #define in the header. This means, the canonical
> maintainer already assumes certain types to be of certain size,
> so one just needs the right ones (uint32 etc) and do a
> #define long uint32 (assuming he assumed long to be 32 bits)
> within a header that's included by all relevant sources.
> Um, something like your wrapper, but in-source.
I thought of that too, though perhaps this is a bit harsh because it
unconditionally redefines natural types without even looking at context.
But maybe it could work: the only one that could test that is Ed,
from what I understand.
[snip]
On Sat, 31 Oct 1998, Dave Phillips wrote:
[snip]
> Incidentally, Robin's random generation routines are a good candidate
> for merging into the canonical sources, and Hans Mikelson would
> certainly like to see that happen. Whether it does is entirely up to
> jpff.
Both jpff and Mikelson have access to the csound linux sources as
anybody else. If they want to use them it's up to them. After they
integrate it, I'll ask Robin to state precisely which version he'd
like to see in the sources and we'll go ahead with that.
>
> Btw, this is in no way meant as any sort of flame, I'm quite interested
> in your discussion. Thanks, Ed, for making the attempt to place Linux
> Csound on the Alpha, that will be a very neat feather in our collective
> cap.
Indeed. As I said, thanks again to all of you.
I'll try to be more responsive in the next days: I'm swamped until
the end of november but I'm always with you...
ciao ciao
Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: [EMAIL PROTECTED]
Re graphics: A picture is worth 10K words -- but only those to describe
the picture. Hardly any sets of 10K words can be adequately described
with pictures.
