Message written at 24 Jan 1999 11:36:30 +0000
--- Copy of mail to rossb@audiomulch.com ---

>>>>> "Ross" == Ross Bencina  writes:

 Ross> I understand your explanation of oscil. Are all multirate
 Ross> opcodes implemented like this or would it be true to say that
 Ross> sometimes opcodes dynamically select behavior (internally -
 Ross> using if()s or switch()es for example) based on their input
 Ross> types - even though this information is essentially static
 Ross> (could be determined at compile time)? 

There are a number of opcodes with one name that select at compile
time based on the types of their outputs and inputs.  If you have
sources these are fairly clear in entry.c as they ar early in the
table, and have a second field of 0xffff for those selecting on 1
argument and 0xfffe for those selecting on two.  As well as these
entries (say for an opcode foo) you will find foo_a foo_k as later
entries.   This is all done at compile time in rdorch.c; it is an area
i 'rationalised' last summer.  Before that each case was treated
specially.

There are other opcodes where there are two functions to do the
operations at audio or control rate, and they are selected (I think)
by the control mechanism also at compile time.  There are a few
opcodes which determine at runtime the details of the type.  I have
less experience with them (well actually I did not know about them
until Hans started sending me code relating to them).  They relate to
the XINCODE macro in all opcode structs, and I decline to explain at
present (e I do not understand them).  In these cases it is usually 1
test on each k-cycle so the overhead is not great.

 Ross> I am just thinking that if all of these determinations were
 Ross> always performed at compile time (if they are not already),
 Ross> things might be faster (not that they are slow now).

Yes, at a cost in code.  Clearly there is a balance to be struck here,
as you suggest

 Ross> Would I be correct in saying that the current implementation is
 Ross> a trade off between having a million leaf types for every
 Ross> opcode, and the penalty incurred by checking parameter types at
 Ross> runtime. Or is there something more subtle that I am missing.

I think that is largely correct.  Having lots of opcodes would also
slow down parsing as at present it uses linear search to find an
opcode.  I have a long term item on the list to use balanced trees, or
hash or something 'modern'.

 Ross> The reason I ask is that I am trying to assess whether such
 Ross> runtime type indentification techniques are part of csound, and
 Ross> hence whether that is a reasonable (if not optimal) way of
 Ross> doing things. 

My own view is that the compromise is reasonable, but the age of some
of the code is showing and could be tightened up with better speed and
possibly better transparency.  On the other hand I seem to be alone in
not having much trouble reading the code, even with macros and without
comments.  This might be related to my age being similar to Barry's,
or my mind being irrecably stuck in the 1960s.

==John ffitch

Sorry about delay; I let mail get out of hand this month and I am