Re: Too many opcodes

Dan Sugalski <[EMAIL PROTECTED]> wrote: > 2) The assembler and PIR compiler need to be taught appropriate > transforms Any objections if I handled unary opcodes with constant arguments inside IMCC? We have still opcodes like: sin_n_nc# sin Nx, 3.14 The created code would be set Nx,

Re: PIC again (was: Too many opcodes)

[Snip] This is interesting. After we're functionally complete we can revisit it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bea

PIC again (was: Too many opcodes)

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 4) A scheme for calling functions. > a) we need a class for a namespace, e.g. the interpreter (Python might >have a "math" object for the call below:) >$P0 = getinterp > b) we do a method call >$N0 = $P0."sin"(3.14) > c) add a method to

Re: Too many opcodes

Dan Sugalski <[EMAIL PROTECTED]> wrote: > ... The answer isn't to reduce the op count. The > answer's to make the cores manageable, which doesn't require tossing > ops out. It seems that it was a bit unclear what my patches did. The confusion seem to arise from the usage of the term opcode. I use

Re: Too many opcodes

At 8:46 PM -0500 11/29/04, Dan Sugalski wrote: It requires being somewhat careful with what ops we put *in*. And since I wasn't clear (This stuff always obviously makes little sense only after I send things...), I meant in the switch/cgoto/jit core loop, not what ops are actually ops. -- Dan

Re: Too many opcodes

At 9:20 AM +0100 11/24/04, Leopold Toetsch wrote: Too many opcodes Bluntly, no. Not too many opcodes. This has been an ongoing issue. I'm well aware that you want to to trim down the opcode count for ages and replace a lot of them with functions with a lightweight calling convention. Wel

Re: Too many opcodes

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 3) Function-like opcodes > Stat, gmtime, seek, tell, send, poll, recv, gcd, lcm, pack, rand, > split, sleep, and what not are all functions in C or perl and any > other language I know. These are *not* opcodes in any hardware CPU I > know (maybe VAXens

Re: Too many opcodes

Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Nov 24, 2004 at 09:20:42AM +0100, Leopold Toetsch wrote: >> 2) Opcode variants with mixed arguments >> >> Honestly >> >>acos Nx, Iy >> >> and tons of other such opcodes are just overkill. > Heck, why do we even have transcendental maths ops

Re: Too many opcodes

On Wed, Nov 24, 2004 at 09:20:42AM +0100, Leopold Toetsch wrote: > 2) Opcode variants with mixed arguments > > Honestly > >acos Nx, Iy > > and tons of other such opcodes are just overkill. If I want a numeric > result, I just pass in a numeric argument. If people really want > that, imcc ha

Too many opcodes

Below are some considerations WRT current opcode count. leo Too many opcodes gcc 2.95.4 doesn't compile the switch core optimized. People have repeatedly reported about troubles with the CGoto core - now the CGP core is as big and compiles as slow. I'm not speaking of the pai