Re: Too many opcodes

2004-12-03 Thread Leopold Toetsch
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: Too many opcodes

2004-11-30 Thread Leopold Toetsch
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 used it

PIC again (was: Too many opcodes)

2004-11-30 Thread Leopold Toetsch
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: PIC again (was: Too many opcodes)

2004-11-30 Thread Dan Sugalski
[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

Re: Too many opcodes

2004-11-29 Thread Dan Sugalski
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. Well, we

Re: Too many opcodes

2004-11-29 Thread Dan Sugalski
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

2004-11-25 Thread Leopold Toetsch
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 have

Too many opcodes

2004-11-24 Thread Leopold Toetsch
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 pain

Re: Too many opcodes

2004-11-24 Thread Leopold Toetsch
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 that take integer