| Hi All,
I've put up an Emscripten version of the latest from the
feature/parser3 branch at:
http://kunstmusik.com/csound-dev-web/
You can also download it as a zip:
http://kunstmusik.com/csound-dev-web.zip
Using the zip locally will be useful if you want to modify the
test.csd externally.
To note, this is based on the Emscripten release. To see console
output, you'll have to use the Javascript Console. This should run in
all browsers.
Regarding Structs, I found an interesting issue today regarding the =
opcode. Right now I added a generic = opcode for copying values from
a struct to a struct. That works at i-time, which is an issue. Note
these two lines:
var2:MyType processMyType var0
; this does not work yet...
var2:MyType = processMyType(var0)
The first writes the output of processMyType directly to var2. The
second line, uses synthetic args and expands out to something like:
#varMyType0 processMyType var0
var2:MyType = #varMyType0
We currently synthesize an argument for all arg types when there is an
expression on the right-hand side of an equals.
Now, this is inefficient, as we introduce a var copy. Also, the above
is problematic due to the generic version of the = opcode being
i-time. I think what we need to do is:
1. If an assignment statement is found with a right-hand expression,
remove the use of synthetic args and replace with direct writing to
the left-hand output var
2. Create a perf-time =, something like "copy", so we can have:
Sval1 copy Sval1
that will run at perf-time and copy values using the CS_TYPE's
copyValue() function.
Right now we have overloads of the = opcode. Some work at perf-time,
others at init-time. We also have init, which only runs at i-time.
Having copy or something like it would be a precise way to specify a
perf-time operation.
Besides this, I see one other major issue at the moment: we currently
always copy by value. This leads to safer code, but on the other
hand, it's inefficient. Adding references to the language (i.e.
pointers) could work, but that would probably be non-trivial to do (I
think it might require altering how we did memory layout/allocation
for instrument instances.) Just something I wanted to note as
something we'll probably have to deal with in the future.
I'll be looking at tackling processing of = with expressions next.
Thanks!
steven
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |