weird code generation
BlitzMax Forums/BlitzMax Programming/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 :) |
   |