weird code generation

Ok heres the deal,
bmax allows you make assignments like this..

matrix[0]=matrix[1]=matrix[2]=matrix[3]= ..
matrix[4]=matrix[5]=0

i expected this to be equivalent to the following..

matrix[0]=0
matrix[1]=0
matrix[2]=0 .......

i use both approaches to create a unit matrix - but having
looked at the assembly code generated for the first
version..its ugly as hell - and im not convinced its even
behaving correctly...i dont know my 8086..but it jst
doesnt look ok...
The second version produces very clean, simple assembly
output...

i would have expected the first version to help the compiler optimise the code..setting the float const once +
writing to the memory addresses..this is not the case

perhaps someone can tell me why the first
version is such an distaster? - perhaps its cuz it doesnt
work like it does in c/c++ ... anyway, jst thought it was
interesting..

The following:

a=b=c

will set a to the result of the comparison between b and c. Presumably that is why the assembly output is so horrible, as the first version is a series of comparisons, not just assignments.

hmmm...that seems counter intuitive - im going to have
another look at the assmebly ouput later + see if can
figure out exactly whats happening..

thanks for that ;)

Its not counter intuitive. Just not the way many might be used from C where such assignement chains work like assignements, not like "comparision assignement"
Due to the (thankfully) missing = == === stuff, it can be misinterpreted.

What happens is:

a=b=c=d -> a=(b=(c=d))

well if thats how it..i guess ill jst have to get used to it,
as for the (thankfully) part of your post - i actually prefer
explicit operators for this...but thats personal opinion...

if nothing else, this post has highlighted a potential problem,
that silly people like me might encounter..

maybe we should have a 'your code is illegible' error message ;)

As for the code it would be easier to do a for..next loop for that.

Im well aware that for/next is simpler - but was looking
at code generation for this particular method. I imagine that
optimised unrolled assignment would result in slightly
quicker intialisation of an array - thats why i was trying this
out - whether or not this is true..im not sure, i dont know
enough about 8086 assembly language coding..i am reading
up on it though..its interesting..

anyway i dont want to start some kind pointless argument
about optimisation and programming methods...
it would seem that this post was of no interest to anyone,
and should perhaps be removed..sorry

Dont dry. I found it interesting.

dont get me wrong, I didnt mean the post isnt interesting. If there is a way to make Max faster im all for it :)