Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote:
>>- do we keep these opcodes?
> Yes.
Ok.
>> If yes some permutations are missing.
> Yeah. I'd as soon leave them out until we need them.
Well, the asymmetry makes it harder for compilers to emit proper
At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote:
We still have a lot of unhooked ops w/o a definite opcode number.
These are mainly the non-branching compare opcodes currently located
in ops/experimental.ops.
These opcodes have some limited usefullness for e.g.
bool_val = (a < b) && (c > d)
i.e
On Sep-06, Jens Rieks wrote:
> Leopold Toetsch wrote:
> > So first:
> > - do we keep these opcodes?
> >If yes some permutations are missing.
> > - if no,? we should either not include experimental.ops in the default
> > opcode set or move it to dynops.
> I have not used them yet, but I think th
Leopold Toetsch wrote:
> So first:
> - do we keep these opcodes?
>If yes some permutations are missing.
> - if no,ยด we should either not include experimental.ops in the default
> opcode set or move it to dynops.
I have not used them yet, but I think that they can be useful.
Has anyone else exce
We still have a lot of unhooked ops w/o a definite opcode number. These
are mainly the non-branching compare opcodes currently located in
ops/experimental.ops.
These opcodes have some limited usefullness for e.g.
bool_val = (a < b) && (c > d)
i.e. for expressions that do not branch on the comp
