At present an opcode can have an arbitrary number of input args, but
the number of outputs is fixed.  So opcodes like vbap can take upto 64
outputs, and in fact always have 64 slots even if they are not used.
I find this just a little annoying.

As we all know every problem in computer science can be solved by
another level of indirection(*), we could in stead have the outputs
accessed via an indirection....

struct {
     OPDS h;
     struct outargs *out;
     ...inputs....
     ...private variable
}

This would of course cost on each initialisation/perf but allows
multiple channel opcodes more easily.  Is it worth the effort, is
there a better way, or should we just not do this
==John ffitch

(*)Attributed to David Wheeler, but probably pointed at Roger Needham

------------------------------------------------------------------------------
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 John,

This is very interesting thought and I think it'd be a bit clearer of
a design to have n-number of args expressed in code.  Plus, it would
allow collapsing some of the hacks like for xin and xout.

I guess though too if we did it for out-args, then it'd make sense to
do the same for in-args too?

One possibility that would allow less work is formalizing var-arg
argtypes.  So if a var-arg type is found in out-args, the engine could
handle creating an outargs struct.  That way, we wouldn't have to
update all opcodes, only those that really have var-args.  This could
fit in nicely with the typesystem stuff I'm working on now, though I
haven't fully analyzed this.

I think I'd lean towards var-arg types as opposed to retrofitting all
opcodes.  Thoughts?

steven

On Sun, Jul 22, 2012 at 12:22 PM, john ffitch  wrote:
> At present an opcode can have an arbitrary number of input args, but
> the number of outputs is fixed.  So opcodes like vbap can take upto 64
> outputs, and in fact always have 64 slots even if they are not used.
> I find this just a little annoying.
>
> As we all know every problem in computer science can be solved by
> another level of indirection(*), we could in stead have the outputs
> accessed via an indirection....
>
> struct {
>      OPDS h;
>      struct outargs *out;
>      ...inputs....
>      ...private variable
> }
>
> This would of course cost on each initialisation/perf but allows
> multiple channel opcodes more easily.  Is it worth the effort, is
> there a better way, or should we just not do this
> ==John ffitch
>
> (*)Attributed to David Wheeler, but probably pointed at Roger Needham
>
> ------------------------------------------------------------------------------
> 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 think both John's idea and Stephen's midification of it are good, and should eliminate some legacy hacks.

Victor

On 23 Jul 2012, at 17:47, Steven Yi  wrote:

> Hi John,
> 
> This is very interesting thought and I think it'd be a bit clearer of
> a design to have n-number of args expressed in code.  Plus, it would
> allow collapsing some of the hacks like for xin and xout.
> 
> I guess though too if we did it for out-args, then it'd make sense to
> do the same for in-args too?
> 
> One possibility that would allow less work is formalizing var-arg
> argtypes.  So if a var-arg type is found in out-args, the engine could
> handle creating an outargs struct.  That way, we wouldn't have to
> update all opcodes, only those that really have var-args.  This could
> fit in nicely with the typesystem stuff I'm working on now, though I
> haven't fully analyzed this.
> 
> I think I'd lean towards var-arg types as opposed to retrofitting all
> opcodes.  Thoughts?
> 
> steven
> 
> On Sun, Jul 22, 2012 at 12:22 PM, john ffitch  wrote:
>> At present an opcode can have an arbitrary number of input args, but
>> the number of outputs is fixed.  So opcodes like vbap can take upto 64
>> outputs, and in fact always have 64 slots even if they are not used.
>> I find this just a little annoying.
>> 
>> As we all know every problem in computer science can be solved by
>> another level of indirection(*), we could in stead have the outputs
>> accessed via an indirection....
>> 
>> struct {
>>     OPDS h;
>>     struct outargs *out;
>>     ...inputs....
>>     ...private variable
>> }
>> 
>> This would of course cost on each initialisation/perf but allows
>> multiple channel opcodes more easily.  Is it worth the effort, is
>> there a better way, or should we just not do this
>> ==John ffitch
>> 
>> (*)Attributed to David Wheeler, but probably pointed at Roger Needham
>> 
>> ------------------------------------------------------------------------------
>> 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

------------------------------------------------------------------------------
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

Inargs should be treated the same as outargs, please...

I think the dynamic sizing is a good idea. The varargs idea is good if
it does not become ambiguous, i.e. if varargs are specified or if they
can be inferred from unambiguous types in the parameter list.

I think this expresses what you are saying and would work out of the box:

typedef boost::variant > arg_t;
std::vector args_t;
args_t inargs;
args_t outargs;

Regards,
Mike


On Mon, Jul 23, 2012 at 12:54 PM, Victor  wrote:
> I think both John's idea and Stephen's midification of it are good, and should eliminate some legacy hacks.
>
> Victor
>
> On 23 Jul 2012, at 17:47, Steven Yi  wrote:
>
>> Hi John,
>>
>> This is very interesting thought and I think it'd be a bit clearer of
>> a design to have n-number of args expressed in code.  Plus, it would
>> allow collapsing some of the hacks like for xin and xout.
>>
>> I guess though too if we did it for out-args, then it'd make sense to
>> do the same for in-args too?
>>
>> One possibility that would allow less work is formalizing var-arg
>> argtypes.  So if a var-arg type is found in out-args, the engine could
>> handle creating an outargs struct.  That way, we wouldn't have to
>> update all opcodes, only those that really have var-args.  This could
>> fit in nicely with the typesystem stuff I'm working on now, though I
>> haven't fully analyzed this.
>>
>> I think I'd lean towards var-arg types as opposed to retrofitting all
>> opcodes.  Thoughts?
>>
>> steven
>>
>> On Sun, Jul 22, 2012 at 12:22 PM, john ffitch  wrote:
>>> At present an opcode can have an arbitrary number of input args, but
>>> the number of outputs is fixed.  So opcodes like vbap can take upto 64
>>> outputs, and in fact always have 64 slots even if they are not used.
>>> I find this just a little annoying.
>>>
>>> As we all know every problem in computer science can be solved by
>>> another level of indirection(*), we could in stead have the outputs
>>> accessed via an indirection....
>>>
>>> struct {
>>>     OPDS h;
>>>     struct outargs *out;
>>>     ...inputs....
>>>     ...private variable
>>> }
>>>
>>> This would of course cost on each initialisation/perf but allows
>>> multiple channel opcodes more easily.  Is it worth the effort, is
>>> there a better way, or should we just not do this
>>> ==John ffitch
>>>
>>> (*)Attributed to David Wheeler, but probably pointed at Roger Needham
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>
> ------------------------------------------------------------------------------
> 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

One thing to note is that args in Csound for opcodes are all pointers.
We'd have to have something like:

typedef struct arg_t{
  void* arg;
  struct arg_t* next;
} ARG;

Runtime initialization of an instrument's memory block could still be
done in one go with pointers setup after that, as it is currently in
Csound.  We'd have to use the lookup table for the mapping of args to
opcode to identify the number of arg spaces to allocate when
considering the total memory size for the instrument instance, then
hookup pointers from there.

On Mon, Jul 23, 2012 at 1:33 PM, Michael Gogins
 wrote:
> Inargs should be treated the same as outargs, please...
>
> I think the dynamic sizing is a good idea. The varargs idea is good if
> it does not become ambiguous, i.e. if varargs are specified or if they
> can be inferred from unambiguous types in the parameter list.
>
> I think this expresses what you are saying and would work out of the box:
>
> typedef boost::variant std::vector > arg_t;
> std::vector args_t;
> args_t inargs;
> args_t outargs;
>
> Regards,
> Mike
>
>
> On Mon, Jul 23, 2012 at 12:54 PM, Victor  wrote:
>> I think both John's idea and Stephen's midification of it are good, and should eliminate some legacy hacks.
>>
>> Victor
>>
>> On 23 Jul 2012, at 17:47, Steven Yi  wrote:
>>
>>> Hi John,
>>>
>>> This is very interesting thought and I think it'd be a bit clearer of
>>> a design to have n-number of args expressed in code.  Plus, it would
>>> allow collapsing some of the hacks like for xin and xout.
>>>
>>> I guess though too if we did it for out-args, then it'd make sense to
>>> do the same for in-args too?
>>>
>>> One possibility that would allow less work is formalizing var-arg
>>> argtypes.  So if a var-arg type is found in out-args, the engine could
>>> handle creating an outargs struct.  That way, we wouldn't have to
>>> update all opcodes, only those that really have var-args.  This could
>>> fit in nicely with the typesystem stuff I'm working on now, though I
>>> haven't fully analyzed this.
>>>
>>> I think I'd lean towards var-arg types as opposed to retrofitting all
>>> opcodes.  Thoughts?
>>>
>>> steven
>>>
>>> On Sun, Jul 22, 2012 at 12:22 PM, john ffitch  wrote:
>>>> At present an opcode can have an arbitrary number of input args, but
>>>> the number of outputs is fixed.  So opcodes like vbap can take upto 64
>>>> outputs, and in fact always have 64 slots even if they are not used.
>>>> I find this just a little annoying.
>>>>
>>>> As we all know every problem in computer science can be solved by
>>>> another level of indirection(*), we could in stead have the outputs
>>>> accessed via an indirection....
>>>>
>>>> struct {
>>>>     OPDS h;
>>>>     struct outargs *out;
>>>>     ...inputs....
>>>>     ...private variable
>>>> }
>>>>
>>>> This would of course cost on each initialisation/perf but allows
>>>> multiple channel opcodes more easily.  Is it worth the effort, is
>>>> there a better way, or should we just not do this
>>>> ==John ffitch
>>>>
>>>> (*)Attributed to David Wheeler, but probably pointed at Roger Needham
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>
>> ------------------------------------------------------------------------------
>> 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