2010/10/23 M.-A. Lemburg <span dir="ltr">&lt;<a href="mailto:mal@egenix.com">mal@egenix.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br></div>
I wish we could get rid off all the byte shifting and div&#39;ery<br>
use in the byte compiler - I&#39;m pretty sure that such operations<br>
are rather slow nowadays compared to working with 16-bit or 32-bit<br>
integers and dropping the notion of taking the word &quot;byte&quot;<br>
in byte code literally.<br></blockquote><div><br></div><div>Unfortunately we can&#39;t remove such shift &amp; masking operations, even on non-byte(code) compilers/VMs.</div><div><br></div><div>In wpython I handle 16 or 32 bits opcodes (it works on multiple of 16 bits words), but I have:</div>
<div>- specialized opcodes to call functions and procedures (functions which trashes the result) which handle the most common cases (84-85% on average from that stats that I have collected from some projects and standard library); I have packed 4 bits nargs and 4 bits nkwargs into a single byte in order to obtain a short (and fast), 16 bits opcode;</div>
<div>- big endian systems still need to extract and &quot;rotate&quot; the bytes to get the correct word(s) value.</div><div><br></div><div>So, even on words (and longwords) representations, they are need.</div><div><br></div>
<div>The good thing is that they can be handled a bit fast because oparg stays in one register, and na and nk vars read (and manipulate) it independently, so a (common) out-of-order processor can do a good work, scheduling and parallelize such instructions, leaving a few final dependencies (when recombining shift and/or mask partial results).</div>
<div>Some work can also be done reordering the instructions to enhance execution on in-order processors.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It may seem strange to have functions, methods or object constructors<br>
with more than 255 parameters, but as I said: when using code generators,<br>
the generators don&#39;t care whether they use 100 or 300 parameters. Even if<br>
just 10 parameters are actually used later on. However, the user<br>
will care a lot if the generators fail due such limits and then become<br>
unusable.<br>
<br>
As example, take a database query method that exposes 3-4 parameters<br>
for each query field. In more complex database schemas that you find<br>
in e.g. data warehouse applications, it is not uncommon to have<br>
100+ query fields or columns in a data table.<br>
<br>
With the current<br>
limit in function/call argument counts, such a model could not be<br>
mapped directly to Python. Instead, you&#39;d have to turn to solutions<br>
based on other data structures that are not automatically checked<br>
by Python when calling methods/functions.<br>
<font color="#888888"><br>
--<br>
</font><div class="im">Marc-Andre Lemburg<br>
</div></blockquote><div><br></div><div>I understood the problem, but I don&#39;t know if this is the correct solution. Anyway, now there&#39;s at least one solution. :)</div><div><br></div><div>Cesare</div>