Hi All,

(Warning: A bit of a long brain storming email!)

I'm looking at the types for inargs/outargs and trying to generalize
them. There are threes things I'm currently looking at: polymorphism,
multi-types, and var-args.

[Polymorphism]

Right now, we have dsblksize being used to determine if an opcode is
polymorphic. I am trying to gather up info to see if the current
system can be simplified.  Right now we have usage following (from
entry1.c):

/* If dsblksize is 0xffff then translate on output arg
                   0xfffe then translate two (oscil)
                   0xfffd then translate on first input arg (peak)
                   0xfffc then translate two (divz)
                   0xfffb then translate on first input arg (loop_l)    */

In looking at a number of these opcodes, the correct version of an
opcode can be ascertained by its input argument types.  For example,
loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
kkkl).  Others like oscil require knowing the types of the output
argument.  I am wondering if we can do a rule such as:

1. Pass 1 - search opcodes by name.
     a. None found - error
     b. One found - check arg types for inputs and outputs.
            aa. If match: success.
            bb. Otherwise: error
     c. Multiple Found: go to pass 2
2. Pass 2 - check on input arg types
     a. None found - error
     b. One found - check out arg types
            aa. If match: success.
            bb. Otherwise: error
     c. Multiple Found: go to pass 3
3. Pass 3 - check on output arg types
     a. None found - error
     b. One found - success
     c. Multiple Found: error

3c would be a pretty bad error, and I'd say it shouldn't be allowed to
happen to have opcode entries added that would lead to ambiguities.

I think with this, it generalizes to just check input args, then
outputs, for disambiguation.  We already do consistency checks to
ensure that the types match in the orch compilation process.

My thought is that parsing could continue to work by just looking up
the name.  A new compiler pass for type checking would be added to
check the opcodes are correct and argument types correct.  If type
checking doesn't pass, abort there.  If all is good, proceed to
optimization, parallel analysis/modification, then compilation.  That
way, by the time the compilation occurs, it can assume type
verification is correct and can just worry about compiling.

Also, my thought is to remove the dsblksize usage for polymorphism,
and instead just allow multiple entries with the same names as long as
the in-args and out-args do not cause an ambiguous situation.  So
instead of:

{ "oscil",   0xfffe, TR                                                 },
{ "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
{ "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
{ "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
{ "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },

it would just be:

{ "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
{ "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
{ "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
{ "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },

This would allow, should one really want to, to have UDO's that override:

opcode oscil a, kaiS
k1,a1,i1,Slabel xin
a1 oscil k1,a1, i1
prints "Oscil %s engaged!", Slabel
xout a1
endop


[Multi-Types]

I'm not sure if this is the correct term, but I am looking at the type
codes section of entry1.c.  Particularly, things like:

T       String or i-rate
U       String or i/k-rate

I think these can be expressed in a type system via subtyping with
multiple parents types.  I'm thinking of this as:

T type found in arglist
S type has T as a parent
i type has T as a parent
i instanceof T : true
S instance T: true

Also, with type promotion, which is inherently done in the compiler
now, we could specify it more formally as:

r is a subtype of i
c is a subtype of i
i is a subtype of k

Therefore, an argument of type r,c, or i can be used in place of a k
arg, but not vice versa.  For arguments that take an a-, we can have a
rule for implicit coercion.

i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a

I'm not sure about type coercion as of yet, but it could be
interesting to look at.

The idea with the formal type system is that the rules would be
generically applied, as opposed to what is currently done in
typetabl.h and the parser/compiler, so that we could have generic
functions to test type compatibility, as well as extending types in
the future.

[Var-args]

Currently we have var args on both the inargs and outargs. We also
have optional input args that default to a value.  Both are concepts
found commonly in languages.  I am not sure yet how to represent
either of those but am researching.


[Other notes]

Beyond the local code changes I have in C, I do have a simple python
script that generates an xml version of the opcode list (at end of
this email). I'm planning to do some preliminary type-checking code
tests with the above assumptions with python scripts to test, with a
focus on the polymorphic opcodes.

Also, in my local repo, I have reorganized the csound6/tests folder
and put them in a sub-folder called csound6/tests/commandline, and
added a new folder called csound6/tests/c.  In the c folder I have
added a unit test for the type system and integrated it into the CMake
build using CTest.  WIth this, one can generate Makefiles and then
type "make test" and it will run the tests.  However, the harness is
currently failing even though the executable when run on its own
return success. I think this has to do with OPCODEDIR64 when run in
the harness not propagating to the test processes, but am still
investigating.

Thanks!
steven



[opcodes.py Python script]

#!/usr/bin/python
import csnd

a = csnd.Csound()
a.Compile('dummy.csd')
ops = csnd.CsoundOpcodeList(a)

out = "\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)

for i in range(ops.Count()):
  out += "\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))

out += "\n"

fout = open("opcodes.xml", "w")
fout.write(out)
fout.flush()
fout.close()

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I like the idea of unambiguous types inferred from inargs and outargs.
If this can be made to work, it should be implemented.

I assume if there are problems doing this for backward compatibility,
we will have special code for these compatibility cases.

Regards,
Mike

On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
> Hi All,
>
> (Warning: A bit of a long brain storming email!)
>
> I'm looking at the types for inargs/outargs and trying to generalize
> them. There are threes things I'm currently looking at: polymorphism,
> multi-types, and var-args.
>
> [Polymorphism]
>
> Right now, we have dsblksize being used to determine if an opcode is
> polymorphic. I am trying to gather up info to see if the current
> system can be simplified.  Right now we have usage following (from
> entry1.c):
>
> /* If dsblksize is 0xffff then translate on output arg
>                    0xfffe then translate two (oscil)
>                    0xfffd then translate on first input arg (peak)
>                    0xfffc then translate two (divz)
>                    0xfffb then translate on first input arg (loop_l)    */
>
> In looking at a number of these opcodes, the correct version of an
> opcode can be ascertained by its input argument types.  For example,
> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
> kkkl).  Others like oscil require knowing the types of the output
> argument.  I am wondering if we can do a rule such as:
>
> 1. Pass 1 - search opcodes by name.
>      a. None found - error
>      b. One found - check arg types for inputs and outputs.
>             aa. If match: success.
>             bb. Otherwise: error
>      c. Multiple Found: go to pass 2
> 2. Pass 2 - check on input arg types
>      a. None found - error
>      b. One found - check out arg types
>             aa. If match: success.
>             bb. Otherwise: error
>      c. Multiple Found: go to pass 3
> 3. Pass 3 - check on output arg types
>      a. None found - error
>      b. One found - success
>      c. Multiple Found: error
>
> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
> happen to have opcode entries added that would lead to ambiguities.
>
> I think with this, it generalizes to just check input args, then
> outputs, for disambiguation.  We already do consistency checks to
> ensure that the types match in the orch compilation process.
>
> My thought is that parsing could continue to work by just looking up
> the name.  A new compiler pass for type checking would be added to
> check the opcodes are correct and argument types correct.  If type
> checking doesn't pass, abort there.  If all is good, proceed to
> optimization, parallel analysis/modification, then compilation.  That
> way, by the time the compilation occurs, it can assume type
> verification is correct and can just worry about compiling.
>
> Also, my thought is to remove the dsblksize usage for polymorphism,
> and instead just allow multiple entries with the same names as long as
> the in-args and out-args do not cause an ambiguous situation.  So
> instead of:
>
> { "oscil",   0xfffe, TR                                                 },
> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>
> it would just be:
>
> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>
> This would allow, should one really want to, to have UDO's that override:
>
> opcode oscil a, kaiS
> k1,a1,i1,Slabel xin
> a1 oscil k1,a1, i1
> prints "Oscil %s engaged!", Slabel
> xout a1
> endop
>
>
> [Multi-Types]
>
> I'm not sure if this is the correct term, but I am looking at the type
> codes section of entry1.c.  Particularly, things like:
>
> T       String or i-rate
> U       String or i/k-rate
>
> I think these can be expressed in a type system via subtyping with
> multiple parents types.  I'm thinking of this as:
>
> T type found in arglist
> S type has T as a parent
> i type has T as a parent
> i instanceof T : true
> S instance T: true
>
> Also, with type promotion, which is inherently done in the compiler
> now, we could specify it more formally as:
>
> r is a subtype of i
> c is a subtype of i
> i is a subtype of k
>
> Therefore, an argument of type r,c, or i can be used in place of a k
> arg, but not vice versa.  For arguments that take an a-, we can have a
> rule for implicit coercion.
>
> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>
> I'm not sure about type coercion as of yet, but it could be
> interesting to look at.
>
> The idea with the formal type system is that the rules would be
> generically applied, as opposed to what is currently done in
> typetabl.h and the parser/compiler, so that we could have generic
> functions to test type compatibility, as well as extending types in
> the future.
>
> [Var-args]
>
> Currently we have var args on both the inargs and outargs. We also
> have optional input args that default to a value.  Both are concepts
> found commonly in languages.  I am not sure yet how to represent
> either of those but am researching.
>
>
> [Other notes]
>
> Beyond the local code changes I have in C, I do have a simple python
> script that generates an xml version of the opcode list (at end of
> this email). I'm planning to do some preliminary type-checking code
> tests with the above assumptions with python scripts to test, with a
> focus on the polymorphic opcodes.
>
> Also, in my local repo, I have reorganized the csound6/tests folder
> and put them in a sub-folder called csound6/tests/commandline, and
> added a new folder called csound6/tests/c.  In the c folder I have
> added a unit test for the type system and integrated it into the CMake
> build using CTest.  WIth this, one can generate Makefiles and then
> type "make test" and it will run the tests.  However, the harness is
> currently failing even though the executable when run on its own
> return success. I think this has to do with OPCODEDIR64 when run in
> the harness not propagating to the test processes, but am still
> investigating.
>
> Thanks!
> steven
>
>
>
> [opcodes.py Python script]
>
> #!/usr/bin/python
> import csnd
>
> a = csnd.Csound()
> a.Compile('dummy.csd')
> ops = csnd.CsoundOpcodeList(a)
>
> out = " version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>
> for i in range(ops.Count()):
>   out += " outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>
> out += "\n"
>
> fout = open("opcodes.xml", "w")
> fout.write(out)
> fout.flush()
> fout.close()
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, I am keenly aware of backwards compatibility, but I am not yet
certain what are the exact issues.  I think part of the python script
tests will be determining what the exact issues are so that we can
hopefully come up with a formal solution (hopefully without special
cases!). :)

On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
 wrote:
> I like the idea of unambiguous types inferred from inargs and outargs.
> If this can be made to work, it should be implemented.
>
> I assume if there are problems doing this for backward compatibility,
> we will have special code for these compatibility cases.
>
> Regards,
> Mike
>
> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>> Hi All,
>>
>> (Warning: A bit of a long brain storming email!)
>>
>> I'm looking at the types for inargs/outargs and trying to generalize
>> them. There are threes things I'm currently looking at: polymorphism,
>> multi-types, and var-args.
>>
>> [Polymorphism]
>>
>> Right now, we have dsblksize being used to determine if an opcode is
>> polymorphic. I am trying to gather up info to see if the current
>> system can be simplified.  Right now we have usage following (from
>> entry1.c):
>>
>> /* If dsblksize is 0xffff then translate on output arg
>>                    0xfffe then translate two (oscil)
>>                    0xfffd then translate on first input arg (peak)
>>                    0xfffc then translate two (divz)
>>                    0xfffb then translate on first input arg (loop_l)    */
>>
>> In looking at a number of these opcodes, the correct version of an
>> opcode can be ascertained by its input argument types.  For example,
>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>> kkkl).  Others like oscil require knowing the types of the output
>> argument.  I am wondering if we can do a rule such as:
>>
>> 1. Pass 1 - search opcodes by name.
>>      a. None found - error
>>      b. One found - check arg types for inputs and outputs.
>>             aa. If match: success.
>>             bb. Otherwise: error
>>      c. Multiple Found: go to pass 2
>> 2. Pass 2 - check on input arg types
>>      a. None found - error
>>      b. One found - check out arg types
>>             aa. If match: success.
>>             bb. Otherwise: error
>>      c. Multiple Found: go to pass 3
>> 3. Pass 3 - check on output arg types
>>      a. None found - error
>>      b. One found - success
>>      c. Multiple Found: error
>>
>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>> happen to have opcode entries added that would lead to ambiguities.
>>
>> I think with this, it generalizes to just check input args, then
>> outputs, for disambiguation.  We already do consistency checks to
>> ensure that the types match in the orch compilation process.
>>
>> My thought is that parsing could continue to work by just looking up
>> the name.  A new compiler pass for type checking would be added to
>> check the opcodes are correct and argument types correct.  If type
>> checking doesn't pass, abort there.  If all is good, proceed to
>> optimization, parallel analysis/modification, then compilation.  That
>> way, by the time the compilation occurs, it can assume type
>> verification is correct and can just worry about compiling.
>>
>> Also, my thought is to remove the dsblksize usage for polymorphism,
>> and instead just allow multiple entries with the same names as long as
>> the in-args and out-args do not cause an ambiguous situation.  So
>> instead of:
>>
>> { "oscil",   0xfffe, TR                                                 },
>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>
>> it would just be:
>>
>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>
>> This would allow, should one really want to, to have UDO's that override:
>>
>> opcode oscil a, kaiS
>> k1,a1,i1,Slabel xin
>> a1 oscil k1,a1, i1
>> prints "Oscil %s engaged!", Slabel
>> xout a1
>> endop
>>
>>
>> [Multi-Types]
>>
>> I'm not sure if this is the correct term, but I am looking at the type
>> codes section of entry1.c.  Particularly, things like:
>>
>> T       String or i-rate
>> U       String or i/k-rate
>>
>> I think these can be expressed in a type system via subtyping with
>> multiple parents types.  I'm thinking of this as:
>>
>> T type found in arglist
>> S type has T as a parent
>> i type has T as a parent
>> i instanceof T : true
>> S instance T: true
>>
>> Also, with type promotion, which is inherently done in the compiler
>> now, we could specify it more formally as:
>>
>> r is a subtype of i
>> c is a subtype of i
>> i is a subtype of k
>>
>> Therefore, an argument of type r,c, or i can be used in place of a k
>> arg, but not vice versa.  For arguments that take an a-, we can have a
>> rule for implicit coercion.
>>
>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>
>> I'm not sure about type coercion as of yet, but it could be
>> interesting to look at.
>>
>> The idea with the formal type system is that the rules would be
>> generically applied, as opposed to what is currently done in
>> typetabl.h and the parser/compiler, so that we could have generic
>> functions to test type compatibility, as well as extending types in
>> the future.
>>
>> [Var-args]
>>
>> Currently we have var args on both the inargs and outargs. We also
>> have optional input args that default to a value.  Both are concepts
>> found commonly in languages.  I am not sure yet how to represent
>> either of those but am researching.
>>
>>
>> [Other notes]
>>
>> Beyond the local code changes I have in C, I do have a simple python
>> script that generates an xml version of the opcode list (at end of
>> this email). I'm planning to do some preliminary type-checking code
>> tests with the above assumptions with python scripts to test, with a
>> focus on the polymorphic opcodes.
>>
>> Also, in my local repo, I have reorganized the csound6/tests folder
>> and put them in a sub-folder called csound6/tests/commandline, and
>> added a new folder called csound6/tests/c.  In the c folder I have
>> added a unit test for the type system and integrated it into the CMake
>> build using CTest.  WIth this, one can generate Makefiles and then
>> type "make test" and it will run the tests.  However, the harness is
>> currently failing even though the executable when run on its own
>> return success. I think this has to do with OPCODEDIR64 when run in
>> the harness not propagating to the test processes, but am still
>> investigating.
>>
>> Thanks!
>> steven
>>
>>
>>
>> [opcodes.py Python script]
>>
>> #!/usr/bin/python
>> import csnd
>>
>> a = csnd.Csound()
>> a.Compile('dummy.csd')
>> ops = csnd.CsoundOpcodeList(a)
>>
>> out = "> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>
>> for i in range(ops.Count()):
>>   out += "> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>
>> out += "\n"
>>
>> fout = open("opcodes.xml", "w")
>> fout.write(out)
>> fout.flush()
>> fout.close()
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

Not sure if anyone else will find this useful, but I just did some
scripting to get a list of polymorphic opcodes in Csound.  These are
from entry1.c and the .c files in csound/Opcodes folder.

Thanks!
steven


Opcode Type 0xFFFB
loop_ge
loop_gt
loop_le
loop_lt


Opcode Type 0xFFFC
divz


Opcode Type 0xFFFD
peak


Opcode Type 0xFFFE
oscil
oscil3
oscili
oscilikt
poscil
poscil3
ptablew
tablew
tablewkt


Opcode Type 0xFFFF
active
betarand
bexprnd
cauchy
cauchyi
cent
chanctrl
cpsmidib
ctrl14
ctrl21
ctrl7
cuserrnd
db
duserrnd
exprand
exprandi
filter2
gauss
gaussi
gendy
gendyc
gendyx
init
limit
linrand
max
maxabs
midic14
midic21
midic7
midictrl
min
minabs
mirror
ntrpol
octave
octmidib
pcauchy
pchbend
pchmidib
poisson
polyaft
pow
ptable
ptable3
ptablei
random
rnd31
rtclock
s16b14
s32b14
semitone
slider16
slider32
slider64
slider8
table
table3
tablei
tableng
taninv2
timek
times
trirand
unirand
urandom
weibull
wrap


On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
> Yes, I am keenly aware of backwards compatibility, but I am not yet
> certain what are the exact issues.  I think part of the python script
> tests will be determining what the exact issues are so that we can
> hopefully come up with a formal solution (hopefully without special
> cases!). :)
>
> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>  wrote:
>> I like the idea of unambiguous types inferred from inargs and outargs.
>> If this can be made to work, it should be implemented.
>>
>> I assume if there are problems doing this for backward compatibility,
>> we will have special code for these compatibility cases.
>>
>> Regards,
>> Mike
>>
>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> (Warning: A bit of a long brain storming email!)
>>>
>>> I'm looking at the types for inargs/outargs and trying to generalize
>>> them. There are threes things I'm currently looking at: polymorphism,
>>> multi-types, and var-args.
>>>
>>> [Polymorphism]
>>>
>>> Right now, we have dsblksize being used to determine if an opcode is
>>> polymorphic. I am trying to gather up info to see if the current
>>> system can be simplified.  Right now we have usage following (from
>>> entry1.c):
>>>
>>> /* If dsblksize is 0xffff then translate on output arg
>>>                    0xfffe then translate two (oscil)
>>>                    0xfffd then translate on first input arg (peak)
>>>                    0xfffc then translate two (divz)
>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>
>>> In looking at a number of these opcodes, the correct version of an
>>> opcode can be ascertained by its input argument types.  For example,
>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>> kkkl).  Others like oscil require knowing the types of the output
>>> argument.  I am wondering if we can do a rule such as:
>>>
>>> 1. Pass 1 - search opcodes by name.
>>>      a. None found - error
>>>      b. One found - check arg types for inputs and outputs.
>>>             aa. If match: success.
>>>             bb. Otherwise: error
>>>      c. Multiple Found: go to pass 2
>>> 2. Pass 2 - check on input arg types
>>>      a. None found - error
>>>      b. One found - check out arg types
>>>             aa. If match: success.
>>>             bb. Otherwise: error
>>>      c. Multiple Found: go to pass 3
>>> 3. Pass 3 - check on output arg types
>>>      a. None found - error
>>>      b. One found - success
>>>      c. Multiple Found: error
>>>
>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>> happen to have opcode entries added that would lead to ambiguities.
>>>
>>> I think with this, it generalizes to just check input args, then
>>> outputs, for disambiguation.  We already do consistency checks to
>>> ensure that the types match in the orch compilation process.
>>>
>>> My thought is that parsing could continue to work by just looking up
>>> the name.  A new compiler pass for type checking would be added to
>>> check the opcodes are correct and argument types correct.  If type
>>> checking doesn't pass, abort there.  If all is good, proceed to
>>> optimization, parallel analysis/modification, then compilation.  That
>>> way, by the time the compilation occurs, it can assume type
>>> verification is correct and can just worry about compiling.
>>>
>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>> and instead just allow multiple entries with the same names as long as
>>> the in-args and out-args do not cause an ambiguous situation.  So
>>> instead of:
>>>
>>> { "oscil",   0xfffe, TR                                                 },
>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>
>>> it would just be:
>>>
>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>
>>> This would allow, should one really want to, to have UDO's that override:
>>>
>>> opcode oscil a, kaiS
>>> k1,a1,i1,Slabel xin
>>> a1 oscil k1,a1, i1
>>> prints "Oscil %s engaged!", Slabel
>>> xout a1
>>> endop
>>>
>>>
>>> [Multi-Types]
>>>
>>> I'm not sure if this is the correct term, but I am looking at the type
>>> codes section of entry1.c.  Particularly, things like:
>>>
>>> T       String or i-rate
>>> U       String or i/k-rate
>>>
>>> I think these can be expressed in a type system via subtyping with
>>> multiple parents types.  I'm thinking of this as:
>>>
>>> T type found in arglist
>>> S type has T as a parent
>>> i type has T as a parent
>>> i instanceof T : true
>>> S instance T: true
>>>
>>> Also, with type promotion, which is inherently done in the compiler
>>> now, we could specify it more formally as:
>>>
>>> r is a subtype of i
>>> c is a subtype of i
>>> i is a subtype of k
>>>
>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>> rule for implicit coercion.
>>>
>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>
>>> I'm not sure about type coercion as of yet, but it could be
>>> interesting to look at.
>>>
>>> The idea with the formal type system is that the rules would be
>>> generically applied, as opposed to what is currently done in
>>> typetabl.h and the parser/compiler, so that we could have generic
>>> functions to test type compatibility, as well as extending types in
>>> the future.
>>>
>>> [Var-args]
>>>
>>> Currently we have var args on both the inargs and outargs. We also
>>> have optional input args that default to a value.  Both are concepts
>>> found commonly in languages.  I am not sure yet how to represent
>>> either of those but am researching.
>>>
>>>
>>> [Other notes]
>>>
>>> Beyond the local code changes I have in C, I do have a simple python
>>> script that generates an xml version of the opcode list (at end of
>>> this email). I'm planning to do some preliminary type-checking code
>>> tests with the above assumptions with python scripts to test, with a
>>> focus on the polymorphic opcodes.
>>>
>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>> and put them in a sub-folder called csound6/tests/commandline, and
>>> added a new folder called csound6/tests/c.  In the c folder I have
>>> added a unit test for the type system and integrated it into the CMake
>>> build using CTest.  WIth this, one can generate Makefiles and then
>>> type "make test" and it will run the tests.  However, the harness is
>>> currently failing even though the executable when run on its own
>>> return success. I think this has to do with OPCODEDIR64 when run in
>>> the harness not propagating to the test processes, but am still
>>> investigating.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>>
>>> [opcodes.py Python script]
>>>
>>> #!/usr/bin/python
>>> import csnd
>>>
>>> a = csnd.Csound()
>>> a.Compile('dummy.csd')
>>> ops = csnd.CsoundOpcodeList(a)
>>>
>>> out = ">> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>
>>> for i in range(ops.Count()):
>>>   out += ">> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>
>>> out += "\n"
>>>
>>> fout = open("opcodes.xml", "w")
>>> fout.write(out)
>>> fout.flush()
>>> fout.close()
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

So, that means in each case for each polymorphic variant of the
opcode, the union of inarg types and outarg types is unique?

Regards,
Mike

On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
> Hi All,
>
> Not sure if anyone else will find this useful, but I just did some
> scripting to get a list of polymorphic opcodes in Csound.  These are
> from entry1.c and the .c files in csound/Opcodes folder.
>
> Thanks!
> steven
>
>
> Opcode Type 0xFFFB
> loop_ge
> loop_gt
> loop_le
> loop_lt
>
>
> Opcode Type 0xFFFC
> divz
>
>
> Opcode Type 0xFFFD
> peak
>
>
> Opcode Type 0xFFFE
> oscil
> oscil3
> oscili
> oscilikt
> poscil
> poscil3
> ptablew
> tablew
> tablewkt
>
>
> Opcode Type 0xFFFF
> active
> betarand
> bexprnd
> cauchy
> cauchyi
> cent
> chanctrl
> cpsmidib
> ctrl14
> ctrl21
> ctrl7
> cuserrnd
> db
> duserrnd
> exprand
> exprandi
> filter2
> gauss
> gaussi
> gendy
> gendyc
> gendyx
> init
> limit
> linrand
> max
> maxabs
> midic14
> midic21
> midic7
> midictrl
> min
> minabs
> mirror
> ntrpol
> octave
> octmidib
> pcauchy
> pchbend
> pchmidib
> poisson
> polyaft
> pow
> ptable
> ptable3
> ptablei
> random
> rnd31
> rtclock
> s16b14
> s32b14
> semitone
> slider16
> slider32
> slider64
> slider8
> table
> table3
> tablei
> tableng
> taninv2
> timek
> times
> trirand
> unirand
> urandom
> weibull
> wrap
>
>
> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>> certain what are the exact issues.  I think part of the python script
>> tests will be determining what the exact issues are so that we can
>> hopefully come up with a formal solution (hopefully without special
>> cases!). :)
>>
>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>  wrote:
>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>> If this can be made to work, it should be implemented.
>>>
>>> I assume if there are problems doing this for backward compatibility,
>>> we will have special code for these compatibility cases.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> (Warning: A bit of a long brain storming email!)
>>>>
>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>> multi-types, and var-args.
>>>>
>>>> [Polymorphism]
>>>>
>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>> polymorphic. I am trying to gather up info to see if the current
>>>> system can be simplified.  Right now we have usage following (from
>>>> entry1.c):
>>>>
>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>                    0xfffe then translate two (oscil)
>>>>                    0xfffd then translate on first input arg (peak)
>>>>                    0xfffc then translate two (divz)
>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>
>>>> In looking at a number of these opcodes, the correct version of an
>>>> opcode can be ascertained by its input argument types.  For example,
>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>> kkkl).  Others like oscil require knowing the types of the output
>>>> argument.  I am wondering if we can do a rule such as:
>>>>
>>>> 1. Pass 1 - search opcodes by name.
>>>>      a. None found - error
>>>>      b. One found - check arg types for inputs and outputs.
>>>>             aa. If match: success.
>>>>             bb. Otherwise: error
>>>>      c. Multiple Found: go to pass 2
>>>> 2. Pass 2 - check on input arg types
>>>>      a. None found - error
>>>>      b. One found - check out arg types
>>>>             aa. If match: success.
>>>>             bb. Otherwise: error
>>>>      c. Multiple Found: go to pass 3
>>>> 3. Pass 3 - check on output arg types
>>>>      a. None found - error
>>>>      b. One found - success
>>>>      c. Multiple Found: error
>>>>
>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>
>>>> I think with this, it generalizes to just check input args, then
>>>> outputs, for disambiguation.  We already do consistency checks to
>>>> ensure that the types match in the orch compilation process.
>>>>
>>>> My thought is that parsing could continue to work by just looking up
>>>> the name.  A new compiler pass for type checking would be added to
>>>> check the opcodes are correct and argument types correct.  If type
>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>> optimization, parallel analysis/modification, then compilation.  That
>>>> way, by the time the compilation occurs, it can assume type
>>>> verification is correct and can just worry about compiling.
>>>>
>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>> and instead just allow multiple entries with the same names as long as
>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>> instead of:
>>>>
>>>> { "oscil",   0xfffe, TR                                                 },
>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>
>>>> it would just be:
>>>>
>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>
>>>> This would allow, should one really want to, to have UDO's that override:
>>>>
>>>> opcode oscil a, kaiS
>>>> k1,a1,i1,Slabel xin
>>>> a1 oscil k1,a1, i1
>>>> prints "Oscil %s engaged!", Slabel
>>>> xout a1
>>>> endop
>>>>
>>>>
>>>> [Multi-Types]
>>>>
>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>> codes section of entry1.c.  Particularly, things like:
>>>>
>>>> T       String or i-rate
>>>> U       String or i/k-rate
>>>>
>>>> I think these can be expressed in a type system via subtyping with
>>>> multiple parents types.  I'm thinking of this as:
>>>>
>>>> T type found in arglist
>>>> S type has T as a parent
>>>> i type has T as a parent
>>>> i instanceof T : true
>>>> S instance T: true
>>>>
>>>> Also, with type promotion, which is inherently done in the compiler
>>>> now, we could specify it more formally as:
>>>>
>>>> r is a subtype of i
>>>> c is a subtype of i
>>>> i is a subtype of k
>>>>
>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>> rule for implicit coercion.
>>>>
>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>
>>>> I'm not sure about type coercion as of yet, but it could be
>>>> interesting to look at.
>>>>
>>>> The idea with the formal type system is that the rules would be
>>>> generically applied, as opposed to what is currently done in
>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>> functions to test type compatibility, as well as extending types in
>>>> the future.
>>>>
>>>> [Var-args]
>>>>
>>>> Currently we have var args on both the inargs and outargs. We also
>>>> have optional input args that default to a value.  Both are concepts
>>>> found commonly in languages.  I am not sure yet how to represent
>>>> either of those but am researching.
>>>>
>>>>
>>>> [Other notes]
>>>>
>>>> Beyond the local code changes I have in C, I do have a simple python
>>>> script that generates an xml version of the opcode list (at end of
>>>> this email). I'm planning to do some preliminary type-checking code
>>>> tests with the above assumptions with python scripts to test, with a
>>>> focus on the polymorphic opcodes.
>>>>
>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>> added a unit test for the type system and integrated it into the CMake
>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>> type "make test" and it will run the tests.  However, the harness is
>>>> currently failing even though the executable when run on its own
>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>> the harness not propagating to the test processes, but am still
>>>> investigating.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>>
>>>> [opcodes.py Python script]
>>>>
>>>> #!/usr/bin/python
>>>> import csnd
>>>>
>>>> a = csnd.Csound()
>>>> a.Compile('dummy.csd')
>>>> ops = csnd.CsoundOpcodeList(a)
>>>>
>>>> out = ">>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>
>>>> for i in range(ops.Count()):
>>>>   out += ">>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>
>>>> out += "\n"
>>>>
>>>> fout = open("opcodes.xml", "w")
>>>> fout.write(out)
>>>> fout.flush()
>>>> fout.close()
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm not quite sure yet, as I just got to this point of making this
list.  The CsoundOpcodeList that is accessible from the API didn't
have dsblksize information, so it took some time to grep and  script
to get that information from the source files.  I can use this info
now with what is returned in CsoundOpcodeList to start writing some
testing scripts.  I'll continue on with this tomorrow and hopefully
make some progress from here.

On Wed, Jul 18, 2012 at 6:31 PM, Michael Gogins
 wrote:
> So, that means in each case for each polymorphic variant of the
> opcode, the union of inarg types and outarg types is unique?
>
> Regards,
> Mike
>
> On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
>> Hi All,
>>
>> Not sure if anyone else will find this useful, but I just did some
>> scripting to get a list of polymorphic opcodes in Csound.  These are
>> from entry1.c and the .c files in csound/Opcodes folder.
>>
>> Thanks!
>> steven
>>
>>
>> Opcode Type 0xFFFB
>> loop_ge
>> loop_gt
>> loop_le
>> loop_lt
>>
>>
>> Opcode Type 0xFFFC
>> divz
>>
>>
>> Opcode Type 0xFFFD
>> peak
>>
>>
>> Opcode Type 0xFFFE
>> oscil
>> oscil3
>> oscili
>> oscilikt
>> poscil
>> poscil3
>> ptablew
>> tablew
>> tablewkt
>>
>>
>> Opcode Type 0xFFFF
>> active
>> betarand
>> bexprnd
>> cauchy
>> cauchyi
>> cent
>> chanctrl
>> cpsmidib
>> ctrl14
>> ctrl21
>> ctrl7
>> cuserrnd
>> db
>> duserrnd
>> exprand
>> exprandi
>> filter2
>> gauss
>> gaussi
>> gendy
>> gendyc
>> gendyx
>> init
>> limit
>> linrand
>> max
>> maxabs
>> midic14
>> midic21
>> midic7
>> midictrl
>> min
>> minabs
>> mirror
>> ntrpol
>> octave
>> octmidib
>> pcauchy
>> pchbend
>> pchmidib
>> poisson
>> polyaft
>> pow
>> ptable
>> ptable3
>> ptablei
>> random
>> rnd31
>> rtclock
>> s16b14
>> s32b14
>> semitone
>> slider16
>> slider32
>> slider64
>> slider8
>> table
>> table3
>> tablei
>> tableng
>> taninv2
>> timek
>> times
>> trirand
>> unirand
>> urandom
>> weibull
>> wrap
>>
>>
>> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>>> certain what are the exact issues.  I think part of the python script
>>> tests will be determining what the exact issues are so that we can
>>> hopefully come up with a formal solution (hopefully without special
>>> cases!). :)
>>>
>>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>>  wrote:
>>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>>> If this can be made to work, it should be implemented.
>>>>
>>>> I assume if there are problems doing this for backward compatibility,
>>>> we will have special code for these compatibility cases.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> (Warning: A bit of a long brain storming email!)
>>>>>
>>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>>> multi-types, and var-args.
>>>>>
>>>>> [Polymorphism]
>>>>>
>>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>>> polymorphic. I am trying to gather up info to see if the current
>>>>> system can be simplified.  Right now we have usage following (from
>>>>> entry1.c):
>>>>>
>>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>>                    0xfffe then translate two (oscil)
>>>>>                    0xfffd then translate on first input arg (peak)
>>>>>                    0xfffc then translate two (divz)
>>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>>
>>>>> In looking at a number of these opcodes, the correct version of an
>>>>> opcode can be ascertained by its input argument types.  For example,
>>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>>> kkkl).  Others like oscil require knowing the types of the output
>>>>> argument.  I am wondering if we can do a rule such as:
>>>>>
>>>>> 1. Pass 1 - search opcodes by name.
>>>>>      a. None found - error
>>>>>      b. One found - check arg types for inputs and outputs.
>>>>>             aa. If match: success.
>>>>>             bb. Otherwise: error
>>>>>      c. Multiple Found: go to pass 2
>>>>> 2. Pass 2 - check on input arg types
>>>>>      a. None found - error
>>>>>      b. One found - check out arg types
>>>>>             aa. If match: success.
>>>>>             bb. Otherwise: error
>>>>>      c. Multiple Found: go to pass 3
>>>>> 3. Pass 3 - check on output arg types
>>>>>      a. None found - error
>>>>>      b. One found - success
>>>>>      c. Multiple Found: error
>>>>>
>>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>>
>>>>> I think with this, it generalizes to just check input args, then
>>>>> outputs, for disambiguation.  We already do consistency checks to
>>>>> ensure that the types match in the orch compilation process.
>>>>>
>>>>> My thought is that parsing could continue to work by just looking up
>>>>> the name.  A new compiler pass for type checking would be added to
>>>>> check the opcodes are correct and argument types correct.  If type
>>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>>> optimization, parallel analysis/modification, then compilation.  That
>>>>> way, by the time the compilation occurs, it can assume type
>>>>> verification is correct and can just worry about compiling.
>>>>>
>>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>>> and instead just allow multiple entries with the same names as long as
>>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>>> instead of:
>>>>>
>>>>> { "oscil",   0xfffe, TR                                                 },
>>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>
>>>>> it would just be:
>>>>>
>>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>
>>>>> This would allow, should one really want to, to have UDO's that override:
>>>>>
>>>>> opcode oscil a, kaiS
>>>>> k1,a1,i1,Slabel xin
>>>>> a1 oscil k1,a1, i1
>>>>> prints "Oscil %s engaged!", Slabel
>>>>> xout a1
>>>>> endop
>>>>>
>>>>>
>>>>> [Multi-Types]
>>>>>
>>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>>> codes section of entry1.c.  Particularly, things like:
>>>>>
>>>>> T       String or i-rate
>>>>> U       String or i/k-rate
>>>>>
>>>>> I think these can be expressed in a type system via subtyping with
>>>>> multiple parents types.  I'm thinking of this as:
>>>>>
>>>>> T type found in arglist
>>>>> S type has T as a parent
>>>>> i type has T as a parent
>>>>> i instanceof T : true
>>>>> S instance T: true
>>>>>
>>>>> Also, with type promotion, which is inherently done in the compiler
>>>>> now, we could specify it more formally as:
>>>>>
>>>>> r is a subtype of i
>>>>> c is a subtype of i
>>>>> i is a subtype of k
>>>>>
>>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>>> rule for implicit coercion.
>>>>>
>>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>>
>>>>> I'm not sure about type coercion as of yet, but it could be
>>>>> interesting to look at.
>>>>>
>>>>> The idea with the formal type system is that the rules would be
>>>>> generically applied, as opposed to what is currently done in
>>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>>> functions to test type compatibility, as well as extending types in
>>>>> the future.
>>>>>
>>>>> [Var-args]
>>>>>
>>>>> Currently we have var args on both the inargs and outargs. We also
>>>>> have optional input args that default to a value.  Both are concepts
>>>>> found commonly in languages.  I am not sure yet how to represent
>>>>> either of those but am researching.
>>>>>
>>>>>
>>>>> [Other notes]
>>>>>
>>>>> Beyond the local code changes I have in C, I do have a simple python
>>>>> script that generates an xml version of the opcode list (at end of
>>>>> this email). I'm planning to do some preliminary type-checking code
>>>>> tests with the above assumptions with python scripts to test, with a
>>>>> focus on the polymorphic opcodes.
>>>>>
>>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>>> added a unit test for the type system and integrated it into the CMake
>>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>>> type "make test" and it will run the tests.  However, the harness is
>>>>> currently failing even though the executable when run on its own
>>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>>> the harness not propagating to the test processes, but am still
>>>>> investigating.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> [opcodes.py Python script]
>>>>>
>>>>> #!/usr/bin/python
>>>>> import csnd
>>>>>
>>>>> a = csnd.Csound()
>>>>> a.Compile('dummy.csd')
>>>>> ops = csnd.CsoundOpcodeList(a)
>>>>>
>>>>> out = ">>>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>>
>>>>> for i in range(ops.Count()):
>>>>>   out += ">>>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>>
>>>>> out += "\n"
>>>>>
>>>>> fout = open("opcodes.xml", "w")
>>>>> fout.write(out)
>>>>> fout.flush()
>>>>> fout.close()
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We should change the API to output all the data that we need in an
easy to use form.

By the way, I've been using valgrind routinely now in developing my
new code. Don't know how I lived without it. So far, just using
--tool=callgrind and viewing results with kcachegrind.

Regards,
Mike

On Wed, Jul 18, 2012 at 6:52 PM, Steven Yi  wrote:
> I'm not quite sure yet, as I just got to this point of making this
> list.  The CsoundOpcodeList that is accessible from the API didn't
> have dsblksize information, so it took some time to grep and  script
> to get that information from the source files.  I can use this info
> now with what is returned in CsoundOpcodeList to start writing some
> testing scripts.  I'll continue on with this tomorrow and hopefully
> make some progress from here.
>
> On Wed, Jul 18, 2012 at 6:31 PM, Michael Gogins
>  wrote:
>> So, that means in each case for each polymorphic variant of the
>> opcode, the union of inarg types and outarg types is unique?
>>
>> Regards,
>> Mike
>>
>> On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> Not sure if anyone else will find this useful, but I just did some
>>> scripting to get a list of polymorphic opcodes in Csound.  These are
>>> from entry1.c and the .c files in csound/Opcodes folder.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> Opcode Type 0xFFFB
>>> loop_ge
>>> loop_gt
>>> loop_le
>>> loop_lt
>>>
>>>
>>> Opcode Type 0xFFFC
>>> divz
>>>
>>>
>>> Opcode Type 0xFFFD
>>> peak
>>>
>>>
>>> Opcode Type 0xFFFE
>>> oscil
>>> oscil3
>>> oscili
>>> oscilikt
>>> poscil
>>> poscil3
>>> ptablew
>>> tablew
>>> tablewkt
>>>
>>>
>>> Opcode Type 0xFFFF
>>> active
>>> betarand
>>> bexprnd
>>> cauchy
>>> cauchyi
>>> cent
>>> chanctrl
>>> cpsmidib
>>> ctrl14
>>> ctrl21
>>> ctrl7
>>> cuserrnd
>>> db
>>> duserrnd
>>> exprand
>>> exprandi
>>> filter2
>>> gauss
>>> gaussi
>>> gendy
>>> gendyc
>>> gendyx
>>> init
>>> limit
>>> linrand
>>> max
>>> maxabs
>>> midic14
>>> midic21
>>> midic7
>>> midictrl
>>> min
>>> minabs
>>> mirror
>>> ntrpol
>>> octave
>>> octmidib
>>> pcauchy
>>> pchbend
>>> pchmidib
>>> poisson
>>> polyaft
>>> pow
>>> ptable
>>> ptable3
>>> ptablei
>>> random
>>> rnd31
>>> rtclock
>>> s16b14
>>> s32b14
>>> semitone
>>> slider16
>>> slider32
>>> slider64
>>> slider8
>>> table
>>> table3
>>> tablei
>>> tableng
>>> taninv2
>>> timek
>>> times
>>> trirand
>>> unirand
>>> urandom
>>> weibull
>>> wrap
>>>
>>>
>>> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>>>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>>>> certain what are the exact issues.  I think part of the python script
>>>> tests will be determining what the exact issues are so that we can
>>>> hopefully come up with a formal solution (hopefully without special
>>>> cases!). :)
>>>>
>>>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>>>  wrote:
>>>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>>>> If this can be made to work, it should be implemented.
>>>>>
>>>>> I assume if there are problems doing this for backward compatibility,
>>>>> we will have special code for these compatibility cases.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> (Warning: A bit of a long brain storming email!)
>>>>>>
>>>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>>>> multi-types, and var-args.
>>>>>>
>>>>>> [Polymorphism]
>>>>>>
>>>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>>>> polymorphic. I am trying to gather up info to see if the current
>>>>>> system can be simplified.  Right now we have usage following (from
>>>>>> entry1.c):
>>>>>>
>>>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>>>                    0xfffe then translate two (oscil)
>>>>>>                    0xfffd then translate on first input arg (peak)
>>>>>>                    0xfffc then translate two (divz)
>>>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>>>
>>>>>> In looking at a number of these opcodes, the correct version of an
>>>>>> opcode can be ascertained by its input argument types.  For example,
>>>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>>>> kkkl).  Others like oscil require knowing the types of the output
>>>>>> argument.  I am wondering if we can do a rule such as:
>>>>>>
>>>>>> 1. Pass 1 - search opcodes by name.
>>>>>>      a. None found - error
>>>>>>      b. One found - check arg types for inputs and outputs.
>>>>>>             aa. If match: success.
>>>>>>             bb. Otherwise: error
>>>>>>      c. Multiple Found: go to pass 2
>>>>>> 2. Pass 2 - check on input arg types
>>>>>>      a. None found - error
>>>>>>      b. One found - check out arg types
>>>>>>             aa. If match: success.
>>>>>>             bb. Otherwise: error
>>>>>>      c. Multiple Found: go to pass 3
>>>>>> 3. Pass 3 - check on output arg types
>>>>>>      a. None found - error
>>>>>>      b. One found - success
>>>>>>      c. Multiple Found: error
>>>>>>
>>>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>>>
>>>>>> I think with this, it generalizes to just check input args, then
>>>>>> outputs, for disambiguation.  We already do consistency checks to
>>>>>> ensure that the types match in the orch compilation process.
>>>>>>
>>>>>> My thought is that parsing could continue to work by just looking up
>>>>>> the name.  A new compiler pass for type checking would be added to
>>>>>> check the opcodes are correct and argument types correct.  If type
>>>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>>>> optimization, parallel analysis/modification, then compilation.  That
>>>>>> way, by the time the compilation occurs, it can assume type
>>>>>> verification is correct and can just worry about compiling.
>>>>>>
>>>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>>>> and instead just allow multiple entries with the same names as long as
>>>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>>>> instead of:
>>>>>>
>>>>>> { "oscil",   0xfffe, TR                                                 },
>>>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>
>>>>>> it would just be:
>>>>>>
>>>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>
>>>>>> This would allow, should one really want to, to have UDO's that override:
>>>>>>
>>>>>> opcode oscil a, kaiS
>>>>>> k1,a1,i1,Slabel xin
>>>>>> a1 oscil k1,a1, i1
>>>>>> prints "Oscil %s engaged!", Slabel
>>>>>> xout a1
>>>>>> endop
>>>>>>
>>>>>>
>>>>>> [Multi-Types]
>>>>>>
>>>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>>>> codes section of entry1.c.  Particularly, things like:
>>>>>>
>>>>>> T       String or i-rate
>>>>>> U       String or i/k-rate
>>>>>>
>>>>>> I think these can be expressed in a type system via subtyping with
>>>>>> multiple parents types.  I'm thinking of this as:
>>>>>>
>>>>>> T type found in arglist
>>>>>> S type has T as a parent
>>>>>> i type has T as a parent
>>>>>> i instanceof T : true
>>>>>> S instance T: true
>>>>>>
>>>>>> Also, with type promotion, which is inherently done in the compiler
>>>>>> now, we could specify it more formally as:
>>>>>>
>>>>>> r is a subtype of i
>>>>>> c is a subtype of i
>>>>>> i is a subtype of k
>>>>>>
>>>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>>>> rule for implicit coercion.
>>>>>>
>>>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>>>
>>>>>> I'm not sure about type coercion as of yet, but it could be
>>>>>> interesting to look at.
>>>>>>
>>>>>> The idea with the formal type system is that the rules would be
>>>>>> generically applied, as opposed to what is currently done in
>>>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>>>> functions to test type compatibility, as well as extending types in
>>>>>> the future.
>>>>>>
>>>>>> [Var-args]
>>>>>>
>>>>>> Currently we have var args on both the inargs and outargs. We also
>>>>>> have optional input args that default to a value.  Both are concepts
>>>>>> found commonly in languages.  I am not sure yet how to represent
>>>>>> either of those but am researching.
>>>>>>
>>>>>>
>>>>>> [Other notes]
>>>>>>
>>>>>> Beyond the local code changes I have in C, I do have a simple python
>>>>>> script that generates an xml version of the opcode list (at end of
>>>>>> this email). I'm planning to do some preliminary type-checking code
>>>>>> tests with the above assumptions with python scripts to test, with a
>>>>>> focus on the polymorphic opcodes.
>>>>>>
>>>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>>>> added a unit test for the type system and integrated it into the CMake
>>>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>>>> type "make test" and it will run the tests.  However, the harness is
>>>>>> currently failing even though the executable when run on its own
>>>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>>>> the harness not propagating to the test processes, but am still
>>>>>> investigating.
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>>
>>>>>>
>>>>>> [opcodes.py Python script]
>>>>>>
>>>>>> #!/usr/bin/python
>>>>>> import csnd
>>>>>>
>>>>>> a = csnd.Csound()
>>>>>> a.Compile('dummy.csd')
>>>>>> ops = csnd.CsoundOpcodeList(a)
>>>>>>
>>>>>> out = ">>>>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>>>
>>>>>> for i in range(ops.Count()):
>>>>>>   out += ">>>>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>>>
>>>>>> out += "\n"
>>>>>>
>>>>>> fout = open("opcodes.xml", "w")
>>>>>> fout.write(out)
>>>>>> fout.flush()
>>>>>> fout.close()
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I concur, though at the moment, I'm looking for the quickest solution
to keep moving on. :)   I think eventually the CsoundOpcodeList should
be updated though to return more information.

As for valgrind, I never really used it much.  I just installed it
here on OSX. I had used Apple's Instrument for some profiling. I
looked at KCacheGrind's webpage and saw that it profiled cache
hits/misses which is interesting.  I was reading into cache lines and
caches yesterday but still need to read more before something like
kcachegrind would become useful to me.  Thanks for mentioning it
though, will keep it on my radar of things to check out!

steven

On Wed, Jul 18, 2012 at 9:25 PM, Michael Gogins
 wrote:
> We should change the API to output all the data that we need in an
> easy to use form.
>
> By the way, I've been using valgrind routinely now in developing my
> new code. Don't know how I lived without it. So far, just using
> --tool=callgrind and viewing results with kcachegrind.
>
> Regards,
> Mike
>
> On Wed, Jul 18, 2012 at 6:52 PM, Steven Yi  wrote:
>> I'm not quite sure yet, as I just got to this point of making this
>> list.  The CsoundOpcodeList that is accessible from the API didn't
>> have dsblksize information, so it took some time to grep and  script
>> to get that information from the source files.  I can use this info
>> now with what is returned in CsoundOpcodeList to start writing some
>> testing scripts.  I'll continue on with this tomorrow and hopefully
>> make some progress from here.
>>
>> On Wed, Jul 18, 2012 at 6:31 PM, Michael Gogins
>>  wrote:
>>> So, that means in each case for each polymorphic variant of the
>>> opcode, the union of inarg types and outarg types is unique?
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> Not sure if anyone else will find this useful, but I just did some
>>>> scripting to get a list of polymorphic opcodes in Csound.  These are
>>>> from entry1.c and the .c files in csound/Opcodes folder.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>> Opcode Type 0xFFFB
>>>> loop_ge
>>>> loop_gt
>>>> loop_le
>>>> loop_lt
>>>>
>>>>
>>>> Opcode Type 0xFFFC
>>>> divz
>>>>
>>>>
>>>> Opcode Type 0xFFFD
>>>> peak
>>>>
>>>>
>>>> Opcode Type 0xFFFE
>>>> oscil
>>>> oscil3
>>>> oscili
>>>> oscilikt
>>>> poscil
>>>> poscil3
>>>> ptablew
>>>> tablew
>>>> tablewkt
>>>>
>>>>
>>>> Opcode Type 0xFFFF
>>>> active
>>>> betarand
>>>> bexprnd
>>>> cauchy
>>>> cauchyi
>>>> cent
>>>> chanctrl
>>>> cpsmidib
>>>> ctrl14
>>>> ctrl21
>>>> ctrl7
>>>> cuserrnd
>>>> db
>>>> duserrnd
>>>> exprand
>>>> exprandi
>>>> filter2
>>>> gauss
>>>> gaussi
>>>> gendy
>>>> gendyc
>>>> gendyx
>>>> init
>>>> limit
>>>> linrand
>>>> max
>>>> maxabs
>>>> midic14
>>>> midic21
>>>> midic7
>>>> midictrl
>>>> min
>>>> minabs
>>>> mirror
>>>> ntrpol
>>>> octave
>>>> octmidib
>>>> pcauchy
>>>> pchbend
>>>> pchmidib
>>>> poisson
>>>> polyaft
>>>> pow
>>>> ptable
>>>> ptable3
>>>> ptablei
>>>> random
>>>> rnd31
>>>> rtclock
>>>> s16b14
>>>> s32b14
>>>> semitone
>>>> slider16
>>>> slider32
>>>> slider64
>>>> slider8
>>>> table
>>>> table3
>>>> tablei
>>>> tableng
>>>> taninv2
>>>> timek
>>>> times
>>>> trirand
>>>> unirand
>>>> urandom
>>>> weibull
>>>> wrap
>>>>
>>>>
>>>> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>>>>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>>>>> certain what are the exact issues.  I think part of the python script
>>>>> tests will be determining what the exact issues are so that we can
>>>>> hopefully come up with a formal solution (hopefully without special
>>>>> cases!). :)
>>>>>
>>>>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>>>>  wrote:
>>>>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>>>>> If this can be made to work, it should be implemented.
>>>>>>
>>>>>> I assume if there are problems doing this for backward compatibility,
>>>>>> we will have special code for these compatibility cases.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> (Warning: A bit of a long brain storming email!)
>>>>>>>
>>>>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>>>>> multi-types, and var-args.
>>>>>>>
>>>>>>> [Polymorphism]
>>>>>>>
>>>>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>>>>> polymorphic. I am trying to gather up info to see if the current
>>>>>>> system can be simplified.  Right now we have usage following (from
>>>>>>> entry1.c):
>>>>>>>
>>>>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>>>>                    0xfffe then translate two (oscil)
>>>>>>>                    0xfffd then translate on first input arg (peak)
>>>>>>>                    0xfffc then translate two (divz)
>>>>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>>>>
>>>>>>> In looking at a number of these opcodes, the correct version of an
>>>>>>> opcode can be ascertained by its input argument types.  For example,
>>>>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>>>>> kkkl).  Others like oscil require knowing the types of the output
>>>>>>> argument.  I am wondering if we can do a rule such as:
>>>>>>>
>>>>>>> 1. Pass 1 - search opcodes by name.
>>>>>>>      a. None found - error
>>>>>>>      b. One found - check arg types for inputs and outputs.
>>>>>>>             aa. If match: success.
>>>>>>>             bb. Otherwise: error
>>>>>>>      c. Multiple Found: go to pass 2
>>>>>>> 2. Pass 2 - check on input arg types
>>>>>>>      a. None found - error
>>>>>>>      b. One found - check out arg types
>>>>>>>             aa. If match: success.
>>>>>>>             bb. Otherwise: error
>>>>>>>      c. Multiple Found: go to pass 3
>>>>>>> 3. Pass 3 - check on output arg types
>>>>>>>      a. None found - error
>>>>>>>      b. One found - success
>>>>>>>      c. Multiple Found: error
>>>>>>>
>>>>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>>>>
>>>>>>> I think with this, it generalizes to just check input args, then
>>>>>>> outputs, for disambiguation.  We already do consistency checks to
>>>>>>> ensure that the types match in the orch compilation process.
>>>>>>>
>>>>>>> My thought is that parsing could continue to work by just looking up
>>>>>>> the name.  A new compiler pass for type checking would be added to
>>>>>>> check the opcodes are correct and argument types correct.  If type
>>>>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>>>>> optimization, parallel analysis/modification, then compilation.  That
>>>>>>> way, by the time the compilation occurs, it can assume type
>>>>>>> verification is correct and can just worry about compiling.
>>>>>>>
>>>>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>>>>> and instead just allow multiple entries with the same names as long as
>>>>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>>>>> instead of:
>>>>>>>
>>>>>>> { "oscil",   0xfffe, TR                                                 },
>>>>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>
>>>>>>> it would just be:
>>>>>>>
>>>>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>
>>>>>>> This would allow, should one really want to, to have UDO's that override:
>>>>>>>
>>>>>>> opcode oscil a, kaiS
>>>>>>> k1,a1,i1,Slabel xin
>>>>>>> a1 oscil k1,a1, i1
>>>>>>> prints "Oscil %s engaged!", Slabel
>>>>>>> xout a1
>>>>>>> endop
>>>>>>>
>>>>>>>
>>>>>>> [Multi-Types]
>>>>>>>
>>>>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>>>>> codes section of entry1.c.  Particularly, things like:
>>>>>>>
>>>>>>> T       String or i-rate
>>>>>>> U       String or i/k-rate
>>>>>>>
>>>>>>> I think these can be expressed in a type system via subtyping with
>>>>>>> multiple parents types.  I'm thinking of this as:
>>>>>>>
>>>>>>> T type found in arglist
>>>>>>> S type has T as a parent
>>>>>>> i type has T as a parent
>>>>>>> i instanceof T : true
>>>>>>> S instance T: true
>>>>>>>
>>>>>>> Also, with type promotion, which is inherently done in the compiler
>>>>>>> now, we could specify it more formally as:
>>>>>>>
>>>>>>> r is a subtype of i
>>>>>>> c is a subtype of i
>>>>>>> i is a subtype of k
>>>>>>>
>>>>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>>>>> rule for implicit coercion.
>>>>>>>
>>>>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>>>>
>>>>>>> I'm not sure about type coercion as of yet, but it could be
>>>>>>> interesting to look at.
>>>>>>>
>>>>>>> The idea with the formal type system is that the rules would be
>>>>>>> generically applied, as opposed to what is currently done in
>>>>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>>>>> functions to test type compatibility, as well as extending types in
>>>>>>> the future.
>>>>>>>
>>>>>>> [Var-args]
>>>>>>>
>>>>>>> Currently we have var args on both the inargs and outargs. We also
>>>>>>> have optional input args that default to a value.  Both are concepts
>>>>>>> found commonly in languages.  I am not sure yet how to represent
>>>>>>> either of those but am researching.
>>>>>>>
>>>>>>>
>>>>>>> [Other notes]
>>>>>>>
>>>>>>> Beyond the local code changes I have in C, I do have a simple python
>>>>>>> script that generates an xml version of the opcode list (at end of
>>>>>>> this email). I'm planning to do some preliminary type-checking code
>>>>>>> tests with the above assumptions with python scripts to test, with a
>>>>>>> focus on the polymorphic opcodes.
>>>>>>>
>>>>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>>>>> added a unit test for the type system and integrated it into the CMake
>>>>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>>>>> type "make test" and it will run the tests.  However, the harness is
>>>>>>> currently failing even though the executable when run on its own
>>>>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>>>>> the harness not propagating to the test processes, but am still
>>>>>>> investigating.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [opcodes.py Python script]
>>>>>>>
>>>>>>> #!/usr/bin/python
>>>>>>> import csnd
>>>>>>>
>>>>>>> a = csnd.Csound()
>>>>>>> a.Compile('dummy.csd')
>>>>>>> ops = csnd.CsoundOpcodeList(a)
>>>>>>>
>>>>>>> out = ">>>>>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>>>>
>>>>>>> for i in range(ops.Count()):
>>>>>>>   out += ">>>>>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>>>>
>>>>>>> out += "\n"
>>>>>>>
>>>>>>> fout = open("opcodes.xml", "w")
>>>>>>> fout.write(out)
>>>>>>> fout.flush()
>>>>>>> fout.close()
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://www.michael-gogins.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I should be clearer... I use kcachegrid to display the callgrind
results. This is for profiling. It is just like Sun Studio's profiler
on which I learned profiling for SunGard's trading systems.

The trouble it has saved me is immense... usually if there is some
efficiency problem in code, it shows up right away in the profiling
and is not at all obvious any other way. This was true at SunGard and
has been true with Csound.

Best,
Mike

On Wed, Jul 18, 2012 at 10:05 PM, Steven Yi  wrote:
> I concur, though at the moment, I'm looking for the quickest solution
> to keep moving on. :)   I think eventually the CsoundOpcodeList should
> be updated though to return more information.
>
> As for valgrind, I never really used it much.  I just installed it
> here on OSX. I had used Apple's Instrument for some profiling. I
> looked at KCacheGrind's webpage and saw that it profiled cache
> hits/misses which is interesting.  I was reading into cache lines and
> caches yesterday but still need to read more before something like
> kcachegrind would become useful to me.  Thanks for mentioning it
> though, will keep it on my radar of things to check out!
>
> steven
>
> On Wed, Jul 18, 2012 at 9:25 PM, Michael Gogins
>  wrote:
>> We should change the API to output all the data that we need in an
>> easy to use form.
>>
>> By the way, I've been using valgrind routinely now in developing my
>> new code. Don't know how I lived without it. So far, just using
>> --tool=callgrind and viewing results with kcachegrind.
>>
>> Regards,
>> Mike
>>
>> On Wed, Jul 18, 2012 at 6:52 PM, Steven Yi  wrote:
>>> I'm not quite sure yet, as I just got to this point of making this
>>> list.  The CsoundOpcodeList that is accessible from the API didn't
>>> have dsblksize information, so it took some time to grep and  script
>>> to get that information from the source files.  I can use this info
>>> now with what is returned in CsoundOpcodeList to start writing some
>>> testing scripts.  I'll continue on with this tomorrow and hopefully
>>> make some progress from here.
>>>
>>> On Wed, Jul 18, 2012 at 6:31 PM, Michael Gogins
>>>  wrote:
>>>> So, that means in each case for each polymorphic variant of the
>>>> opcode, the union of inarg types and outarg types is unique?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> Not sure if anyone else will find this useful, but I just did some
>>>>> scripting to get a list of polymorphic opcodes in Csound.  These are
>>>>> from entry1.c and the .c files in csound/Opcodes folder.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>> Opcode Type 0xFFFB
>>>>> loop_ge
>>>>> loop_gt
>>>>> loop_le
>>>>> loop_lt
>>>>>
>>>>>
>>>>> Opcode Type 0xFFFC
>>>>> divz
>>>>>
>>>>>
>>>>> Opcode Type 0xFFFD
>>>>> peak
>>>>>
>>>>>
>>>>> Opcode Type 0xFFFE
>>>>> oscil
>>>>> oscil3
>>>>> oscili
>>>>> oscilikt
>>>>> poscil
>>>>> poscil3
>>>>> ptablew
>>>>> tablew
>>>>> tablewkt
>>>>>
>>>>>
>>>>> Opcode Type 0xFFFF
>>>>> active
>>>>> betarand
>>>>> bexprnd
>>>>> cauchy
>>>>> cauchyi
>>>>> cent
>>>>> chanctrl
>>>>> cpsmidib
>>>>> ctrl14
>>>>> ctrl21
>>>>> ctrl7
>>>>> cuserrnd
>>>>> db
>>>>> duserrnd
>>>>> exprand
>>>>> exprandi
>>>>> filter2
>>>>> gauss
>>>>> gaussi
>>>>> gendy
>>>>> gendyc
>>>>> gendyx
>>>>> init
>>>>> limit
>>>>> linrand
>>>>> max
>>>>> maxabs
>>>>> midic14
>>>>> midic21
>>>>> midic7
>>>>> midictrl
>>>>> min
>>>>> minabs
>>>>> mirror
>>>>> ntrpol
>>>>> octave
>>>>> octmidib
>>>>> pcauchy
>>>>> pchbend
>>>>> pchmidib
>>>>> poisson
>>>>> polyaft
>>>>> pow
>>>>> ptable
>>>>> ptable3
>>>>> ptablei
>>>>> random
>>>>> rnd31
>>>>> rtclock
>>>>> s16b14
>>>>> s32b14
>>>>> semitone
>>>>> slider16
>>>>> slider32
>>>>> slider64
>>>>> slider8
>>>>> table
>>>>> table3
>>>>> tablei
>>>>> tableng
>>>>> taninv2
>>>>> timek
>>>>> times
>>>>> trirand
>>>>> unirand
>>>>> urandom
>>>>> weibull
>>>>> wrap
>>>>>
>>>>>
>>>>> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>>>>>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>>>>>> certain what are the exact issues.  I think part of the python script
>>>>>> tests will be determining what the exact issues are so that we can
>>>>>> hopefully come up with a formal solution (hopefully without special
>>>>>> cases!). :)
>>>>>>
>>>>>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>>>>>> If this can be made to work, it should be implemented.
>>>>>>>
>>>>>>> I assume if there are problems doing this for backward compatibility,
>>>>>>> we will have special code for these compatibility cases.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> (Warning: A bit of a long brain storming email!)
>>>>>>>>
>>>>>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>>>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>>>>>> multi-types, and var-args.
>>>>>>>>
>>>>>>>> [Polymorphism]
>>>>>>>>
>>>>>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>>>>>> polymorphic. I am trying to gather up info to see if the current
>>>>>>>> system can be simplified.  Right now we have usage following (from
>>>>>>>> entry1.c):
>>>>>>>>
>>>>>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>>>>>                    0xfffe then translate two (oscil)
>>>>>>>>                    0xfffd then translate on first input arg (peak)
>>>>>>>>                    0xfffc then translate two (divz)
>>>>>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>>>>>
>>>>>>>> In looking at a number of these opcodes, the correct version of an
>>>>>>>> opcode can be ascertained by its input argument types.  For example,
>>>>>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>>>>>> kkkl).  Others like oscil require knowing the types of the output
>>>>>>>> argument.  I am wondering if we can do a rule such as:
>>>>>>>>
>>>>>>>> 1. Pass 1 - search opcodes by name.
>>>>>>>>      a. None found - error
>>>>>>>>      b. One found - check arg types for inputs and outputs.
>>>>>>>>             aa. If match: success.
>>>>>>>>             bb. Otherwise: error
>>>>>>>>      c. Multiple Found: go to pass 2
>>>>>>>> 2. Pass 2 - check on input arg types
>>>>>>>>      a. None found - error
>>>>>>>>      b. One found - check out arg types
>>>>>>>>             aa. If match: success.
>>>>>>>>             bb. Otherwise: error
>>>>>>>>      c. Multiple Found: go to pass 3
>>>>>>>> 3. Pass 3 - check on output arg types
>>>>>>>>      a. None found - error
>>>>>>>>      b. One found - success
>>>>>>>>      c. Multiple Found: error
>>>>>>>>
>>>>>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>>>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>>>>>
>>>>>>>> I think with this, it generalizes to just check input args, then
>>>>>>>> outputs, for disambiguation.  We already do consistency checks to
>>>>>>>> ensure that the types match in the orch compilation process.
>>>>>>>>
>>>>>>>> My thought is that parsing could continue to work by just looking up
>>>>>>>> the name.  A new compiler pass for type checking would be added to
>>>>>>>> check the opcodes are correct and argument types correct.  If type
>>>>>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>>>>>> optimization, parallel analysis/modification, then compilation.  That
>>>>>>>> way, by the time the compilation occurs, it can assume type
>>>>>>>> verification is correct and can just worry about compiling.
>>>>>>>>
>>>>>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>>>>>> and instead just allow multiple entries with the same names as long as
>>>>>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>>>>>> instead of:
>>>>>>>>
>>>>>>>> { "oscil",   0xfffe, TR                                                 },
>>>>>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>>
>>>>>>>> it would just be:
>>>>>>>>
>>>>>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>>
>>>>>>>> This would allow, should one really want to, to have UDO's that override:
>>>>>>>>
>>>>>>>> opcode oscil a, kaiS
>>>>>>>> k1,a1,i1,Slabel xin
>>>>>>>> a1 oscil k1,a1, i1
>>>>>>>> prints "Oscil %s engaged!", Slabel
>>>>>>>> xout a1
>>>>>>>> endop
>>>>>>>>
>>>>>>>>
>>>>>>>> [Multi-Types]
>>>>>>>>
>>>>>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>>>>>> codes section of entry1.c.  Particularly, things like:
>>>>>>>>
>>>>>>>> T       String or i-rate
>>>>>>>> U       String or i/k-rate
>>>>>>>>
>>>>>>>> I think these can be expressed in a type system via subtyping with
>>>>>>>> multiple parents types.  I'm thinking of this as:
>>>>>>>>
>>>>>>>> T type found in arglist
>>>>>>>> S type has T as a parent
>>>>>>>> i type has T as a parent
>>>>>>>> i instanceof T : true
>>>>>>>> S instance T: true
>>>>>>>>
>>>>>>>> Also, with type promotion, which is inherently done in the compiler
>>>>>>>> now, we could specify it more formally as:
>>>>>>>>
>>>>>>>> r is a subtype of i
>>>>>>>> c is a subtype of i
>>>>>>>> i is a subtype of k
>>>>>>>>
>>>>>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>>>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>>>>>> rule for implicit coercion.
>>>>>>>>
>>>>>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>>>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>>>>>
>>>>>>>> I'm not sure about type coercion as of yet, but it could be
>>>>>>>> interesting to look at.
>>>>>>>>
>>>>>>>> The idea with the formal type system is that the rules would be
>>>>>>>> generically applied, as opposed to what is currently done in
>>>>>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>>>>>> functions to test type compatibility, as well as extending types in
>>>>>>>> the future.
>>>>>>>>
>>>>>>>> [Var-args]
>>>>>>>>
>>>>>>>> Currently we have var args on both the inargs and outargs. We also
>>>>>>>> have optional input args that default to a value.  Both are concepts
>>>>>>>> found commonly in languages.  I am not sure yet how to represent
>>>>>>>> either of those but am researching.
>>>>>>>>
>>>>>>>>
>>>>>>>> [Other notes]
>>>>>>>>
>>>>>>>> Beyond the local code changes I have in C, I do have a simple python
>>>>>>>> script that generates an xml version of the opcode list (at end of
>>>>>>>> this email). I'm planning to do some preliminary type-checking code
>>>>>>>> tests with the above assumptions with python scripts to test, with a
>>>>>>>> focus on the polymorphic opcodes.
>>>>>>>>
>>>>>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>>>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>>>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>>>>>> added a unit test for the type system and integrated it into the CMake
>>>>>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>>>>>> type "make test" and it will run the tests.  However, the harness is
>>>>>>>> currently failing even though the executable when run on its own
>>>>>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>>>>>> the harness not propagating to the test processes, but am still
>>>>>>>> investigating.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [opcodes.py Python script]
>>>>>>>>
>>>>>>>> #!/usr/bin/python
>>>>>>>> import csnd
>>>>>>>>
>>>>>>>> a = csnd.Csound()
>>>>>>>> a.Compile('dummy.csd')
>>>>>>>> ops = csnd.CsoundOpcodeList(a)
>>>>>>>>
>>>>>>>> out = ">>>>>>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>>>>>
>>>>>>>> for i in range(ops.Count()):
>>>>>>>>   out += ">>>>>>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>>>>>
>>>>>>>> out += "\n"
>>>>>>>>
>>>>>>>> fout = open("opcodes.xml", "w")
>>>>>>>> fout.write(out)
>>>>>>>> fout.flush()
>>>>>>>> fout.close()
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Live Security Virtual Conference
>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://www.michael-gogins.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Just following up, I made an HTML file that has the results of
searching out polymorphic opcodes.  It's available at:

http://www.kunstmusik.com/polymorphic.html

I think this list is accurate, but may there may be more that are
missing. It looks to me from perusing the tables that the opcodes can
be determined by checking the in-args and out-args together to find
the correct version of an opcode, but am still studying things.

Thanks!
steven

On Wed, Jul 18, 2012 at 10:10 PM, Michael Gogins
 wrote:
> I should be clearer... I use kcachegrid to display the callgrind
> results. This is for profiling. It is just like Sun Studio's profiler
> on which I learned profiling for SunGard's trading systems.
>
> The trouble it has saved me is immense... usually if there is some
> efficiency problem in code, it shows up right away in the profiling
> and is not at all obvious any other way. This was true at SunGard and
> has been true with Csound.
>
> Best,
> Mike
>
> On Wed, Jul 18, 2012 at 10:05 PM, Steven Yi  wrote:
>> I concur, though at the moment, I'm looking for the quickest solution
>> to keep moving on. :)   I think eventually the CsoundOpcodeList should
>> be updated though to return more information.
>>
>> As for valgrind, I never really used it much.  I just installed it
>> here on OSX. I had used Apple's Instrument for some profiling. I
>> looked at KCacheGrind's webpage and saw that it profiled cache
>> hits/misses which is interesting.  I was reading into cache lines and
>> caches yesterday but still need to read more before something like
>> kcachegrind would become useful to me.  Thanks for mentioning it
>> though, will keep it on my radar of things to check out!
>>
>> steven
>>
>> On Wed, Jul 18, 2012 at 9:25 PM, Michael Gogins
>>  wrote:
>>> We should change the API to output all the data that we need in an
>>> easy to use form.
>>>
>>> By the way, I've been using valgrind routinely now in developing my
>>> new code. Don't know how I lived without it. So far, just using
>>> --tool=callgrind and viewing results with kcachegrind.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, Jul 18, 2012 at 6:52 PM, Steven Yi  wrote:
>>>> I'm not quite sure yet, as I just got to this point of making this
>>>> list.  The CsoundOpcodeList that is accessible from the API didn't
>>>> have dsblksize information, so it took some time to grep and  script
>>>> to get that information from the source files.  I can use this info
>>>> now with what is returned in CsoundOpcodeList to start writing some
>>>> testing scripts.  I'll continue on with this tomorrow and hopefully
>>>> make some progress from here.
>>>>
>>>> On Wed, Jul 18, 2012 at 6:31 PM, Michael Gogins
>>>>  wrote:
>>>>> So, that means in each case for each polymorphic variant of the
>>>>> opcode, the union of inarg types and outarg types is unique?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Wed, Jul 18, 2012 at 6:21 PM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Not sure if anyone else will find this useful, but I just did some
>>>>>> scripting to get a list of polymorphic opcodes in Csound.  These are
>>>>>> from entry1.c and the .c files in csound/Opcodes folder.
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>>
>>>>>> Opcode Type 0xFFFB
>>>>>> loop_ge
>>>>>> loop_gt
>>>>>> loop_le
>>>>>> loop_lt
>>>>>>
>>>>>>
>>>>>> Opcode Type 0xFFFC
>>>>>> divz
>>>>>>
>>>>>>
>>>>>> Opcode Type 0xFFFD
>>>>>> peak
>>>>>>
>>>>>>
>>>>>> Opcode Type 0xFFFE
>>>>>> oscil
>>>>>> oscil3
>>>>>> oscili
>>>>>> oscilikt
>>>>>> poscil
>>>>>> poscil3
>>>>>> ptablew
>>>>>> tablew
>>>>>> tablewkt
>>>>>>
>>>>>>
>>>>>> Opcode Type 0xFFFF
>>>>>> active
>>>>>> betarand
>>>>>> bexprnd
>>>>>> cauchy
>>>>>> cauchyi
>>>>>> cent
>>>>>> chanctrl
>>>>>> cpsmidib
>>>>>> ctrl14
>>>>>> ctrl21
>>>>>> ctrl7
>>>>>> cuserrnd
>>>>>> db
>>>>>> duserrnd
>>>>>> exprand
>>>>>> exprandi
>>>>>> filter2
>>>>>> gauss
>>>>>> gaussi
>>>>>> gendy
>>>>>> gendyc
>>>>>> gendyx
>>>>>> init
>>>>>> limit
>>>>>> linrand
>>>>>> max
>>>>>> maxabs
>>>>>> midic14
>>>>>> midic21
>>>>>> midic7
>>>>>> midictrl
>>>>>> min
>>>>>> minabs
>>>>>> mirror
>>>>>> ntrpol
>>>>>> octave
>>>>>> octmidib
>>>>>> pcauchy
>>>>>> pchbend
>>>>>> pchmidib
>>>>>> poisson
>>>>>> polyaft
>>>>>> pow
>>>>>> ptable
>>>>>> ptable3
>>>>>> ptablei
>>>>>> random
>>>>>> rnd31
>>>>>> rtclock
>>>>>> s16b14
>>>>>> s32b14
>>>>>> semitone
>>>>>> slider16
>>>>>> slider32
>>>>>> slider64
>>>>>> slider8
>>>>>> table
>>>>>> table3
>>>>>> tablei
>>>>>> tableng
>>>>>> taninv2
>>>>>> timek
>>>>>> times
>>>>>> trirand
>>>>>> unirand
>>>>>> urandom
>>>>>> weibull
>>>>>> wrap
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 16, 2012 at 9:16 PM, Steven Yi  wrote:
>>>>>>> Yes, I am keenly aware of backwards compatibility, but I am not yet
>>>>>>> certain what are the exact issues.  I think part of the python script
>>>>>>> tests will be determining what the exact issues are so that we can
>>>>>>> hopefully come up with a formal solution (hopefully without special
>>>>>>> cases!). :)
>>>>>>>
>>>>>>> On Mon, Jul 16, 2012 at 8:57 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> I like the idea of unambiguous types inferred from inargs and outargs.
>>>>>>>> If this can be made to work, it should be implemented.
>>>>>>>>
>>>>>>>> I assume if there are problems doing this for backward compatibility,
>>>>>>>> we will have special code for these compatibility cases.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> On Mon, Jul 16, 2012 at 8:29 PM, Steven Yi  wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> (Warning: A bit of a long brain storming email!)
>>>>>>>>>
>>>>>>>>> I'm looking at the types for inargs/outargs and trying to generalize
>>>>>>>>> them. There are threes things I'm currently looking at: polymorphism,
>>>>>>>>> multi-types, and var-args.
>>>>>>>>>
>>>>>>>>> [Polymorphism]
>>>>>>>>>
>>>>>>>>> Right now, we have dsblksize being used to determine if an opcode is
>>>>>>>>> polymorphic. I am trying to gather up info to see if the current
>>>>>>>>> system can be simplified.  Right now we have usage following (from
>>>>>>>>> entry1.c):
>>>>>>>>>
>>>>>>>>> /* If dsblksize is 0xffff then translate on output arg
>>>>>>>>>                    0xfffe then translate two (oscil)
>>>>>>>>>                    0xfffd then translate on first input arg (peak)
>>>>>>>>>                    0xfffc then translate two (divz)
>>>>>>>>>                    0xfffb then translate on first input arg (loop_l)    */
>>>>>>>>>
>>>>>>>>> In looking at a number of these opcodes, the correct version of an
>>>>>>>>> opcode can be ascertained by its input argument types.  For example,
>>>>>>>>> loop_lt.i and loop_lt.k have different input type signatures (iiil vs.
>>>>>>>>> kkkl).  Others like oscil require knowing the types of the output
>>>>>>>>> argument.  I am wondering if we can do a rule such as:
>>>>>>>>>
>>>>>>>>> 1. Pass 1 - search opcodes by name.
>>>>>>>>>      a. None found - error
>>>>>>>>>      b. One found - check arg types for inputs and outputs.
>>>>>>>>>             aa. If match: success.
>>>>>>>>>             bb. Otherwise: error
>>>>>>>>>      c. Multiple Found: go to pass 2
>>>>>>>>> 2. Pass 2 - check on input arg types
>>>>>>>>>      a. None found - error
>>>>>>>>>      b. One found - check out arg types
>>>>>>>>>             aa. If match: success.
>>>>>>>>>             bb. Otherwise: error
>>>>>>>>>      c. Multiple Found: go to pass 3
>>>>>>>>> 3. Pass 3 - check on output arg types
>>>>>>>>>      a. None found - error
>>>>>>>>>      b. One found - success
>>>>>>>>>      c. Multiple Found: error
>>>>>>>>>
>>>>>>>>> 3c would be a pretty bad error, and I'd say it shouldn't be allowed to
>>>>>>>>> happen to have opcode entries added that would lead to ambiguities.
>>>>>>>>>
>>>>>>>>> I think with this, it generalizes to just check input args, then
>>>>>>>>> outputs, for disambiguation.  We already do consistency checks to
>>>>>>>>> ensure that the types match in the orch compilation process.
>>>>>>>>>
>>>>>>>>> My thought is that parsing could continue to work by just looking up
>>>>>>>>> the name.  A new compiler pass for type checking would be added to
>>>>>>>>> check the opcodes are correct and argument types correct.  If type
>>>>>>>>> checking doesn't pass, abort there.  If all is good, proceed to
>>>>>>>>> optimization, parallel analysis/modification, then compilation.  That
>>>>>>>>> way, by the time the compilation occurs, it can assume type
>>>>>>>>> verification is correct and can just worry about compiling.
>>>>>>>>>
>>>>>>>>> Also, my thought is to remove the dsblksize usage for polymorphism,
>>>>>>>>> and instead just allow multiple entries with the same names as long as
>>>>>>>>> the in-args and out-args do not cause an ambiguous situation.  So
>>>>>>>>> instead of:
>>>>>>>>>
>>>>>>>>> { "oscil",   0xfffe, TR                                                 },
>>>>>>>>> { "oscil.kk",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>>>> { "oscil.ka",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>>>> { "oscil.ak",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>>>> { "oscil.aa",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>>>
>>>>>>>>> it would just be:
>>>>>>>>>
>>>>>>>>> { "oscil",S(OSC),    7,      "s",    "kkio", oscset, koscil, osckk   },
>>>>>>>>> { "oscil",S(OSC),    5,      "a",    "kaio", oscset, NULL,   oscka   },
>>>>>>>>> { "oscil",S(OSC),    5,      "a",    "akio", oscset, NULL,   oscak   },
>>>>>>>>> { "oscil",S(OSC),    5,      "a",    "aaio", oscset, NULL,   oscaa   },
>>>>>>>>>
>>>>>>>>> This would allow, should one really want to, to have UDO's that override:
>>>>>>>>>
>>>>>>>>> opcode oscil a, kaiS
>>>>>>>>> k1,a1,i1,Slabel xin
>>>>>>>>> a1 oscil k1,a1, i1
>>>>>>>>> prints "Oscil %s engaged!", Slabel
>>>>>>>>> xout a1
>>>>>>>>> endop
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Multi-Types]
>>>>>>>>>
>>>>>>>>> I'm not sure if this is the correct term, but I am looking at the type
>>>>>>>>> codes section of entry1.c.  Particularly, things like:
>>>>>>>>>
>>>>>>>>> T       String or i-rate
>>>>>>>>> U       String or i/k-rate
>>>>>>>>>
>>>>>>>>> I think these can be expressed in a type system via subtyping with
>>>>>>>>> multiple parents types.  I'm thinking of this as:
>>>>>>>>>
>>>>>>>>> T type found in arglist
>>>>>>>>> S type has T as a parent
>>>>>>>>> i type has T as a parent
>>>>>>>>> i instanceof T : true
>>>>>>>>> S instance T: true
>>>>>>>>>
>>>>>>>>> Also, with type promotion, which is inherently done in the compiler
>>>>>>>>> now, we could specify it more formally as:
>>>>>>>>>
>>>>>>>>> r is a subtype of i
>>>>>>>>> c is a subtype of i
>>>>>>>>> i is a subtype of k
>>>>>>>>>
>>>>>>>>> Therefore, an argument of type r,c, or i can be used in place of a k
>>>>>>>>> arg, but not vice versa.  For arguments that take an a-, we can have a
>>>>>>>>> rule for implicit coercion.
>>>>>>>>>
>>>>>>>>> i can be coerced into a type of a, if "=" opcode is found with inarg i, outarg a
>>>>>>>>> k can be coerced into a type of a, if "=" opcode is found with inarg k, outarg a
>>>>>>>>>
>>>>>>>>> I'm not sure about type coercion as of yet, but it could be
>>>>>>>>> interesting to look at.
>>>>>>>>>
>>>>>>>>> The idea with the formal type system is that the rules would be
>>>>>>>>> generically applied, as opposed to what is currently done in
>>>>>>>>> typetabl.h and the parser/compiler, so that we could have generic
>>>>>>>>> functions to test type compatibility, as well as extending types in
>>>>>>>>> the future.
>>>>>>>>>
>>>>>>>>> [Var-args]
>>>>>>>>>
>>>>>>>>> Currently we have var args on both the inargs and outargs. We also
>>>>>>>>> have optional input args that default to a value.  Both are concepts
>>>>>>>>> found commonly in languages.  I am not sure yet how to represent
>>>>>>>>> either of those but am researching.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Other notes]
>>>>>>>>>
>>>>>>>>> Beyond the local code changes I have in C, I do have a simple python
>>>>>>>>> script that generates an xml version of the opcode list (at end of
>>>>>>>>> this email). I'm planning to do some preliminary type-checking code
>>>>>>>>> tests with the above assumptions with python scripts to test, with a
>>>>>>>>> focus on the polymorphic opcodes.
>>>>>>>>>
>>>>>>>>> Also, in my local repo, I have reorganized the csound6/tests folder
>>>>>>>>> and put them in a sub-folder called csound6/tests/commandline, and
>>>>>>>>> added a new folder called csound6/tests/c.  In the c folder I have
>>>>>>>>> added a unit test for the type system and integrated it into the CMake
>>>>>>>>> build using CTest.  WIth this, one can generate Makefiles and then
>>>>>>>>> type "make test" and it will run the tests.  However, the harness is
>>>>>>>>> currently failing even though the executable when run on its own
>>>>>>>>> return success. I think this has to do with OPCODEDIR64 when run in
>>>>>>>>> the harness not propagating to the test processes, but am still
>>>>>>>>> investigating.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [opcodes.py Python script]
>>>>>>>>>
>>>>>>>>> #!/usr/bin/python
>>>>>>>>> import csnd
>>>>>>>>>
>>>>>>>>> a = csnd.Csound()
>>>>>>>>> a.Compile('dummy.csd')
>>>>>>>>> ops = csnd.CsoundOpcodeList(a)
>>>>>>>>>
>>>>>>>>> out = ">>>>>>>> version=\"%s.%s.%s\">\n"%(csnd.CS_VERSION,csnd.CS_SUBVER,csnd.CS_PATCHLEVEL)
>>>>>>>>>
>>>>>>>>> for i in range(ops.Count()):
>>>>>>>>>   out += ">>>>>>>> outtypes=\"%s\"/>\n"%(ops.Name(i), ops.InTypes(i), ops.OutTypes(i))
>>>>>>>>>
>>>>>>>>> out += "\n"
>>>>>>>>>
>>>>>>>>> fout = open("opcodes.xml", "w")
>>>>>>>>> fout.write(out)
>>>>>>>>> fout.flush()
>>>>>>>>> fout.close()
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Live Security Virtual Conference
>>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://www.michael-gogins.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Live Security Virtual Conference
>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net