On Sat, 2001-09-08 at 22:24, Uri Guttman wrote:
> >>>>> "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
>
>
> BW> =item and tx, ty, tz *
>
> BW> Bitwise And all bits in y with z and store the result in register x.
> BW> (x = y & z)
>
> just a minor thought on parrot assembler argument order. dan seems to
> have picked the result register to be first. my experience with the
> pdp-11 left me with the result on the right. i think the vax (dan's
> favorite) followed dec's tradition and kept the result on the right. is
> this ordering final?
>
gcc output (x86 linux, vax linux): destination on right.
NASM, MASM, TASM (x86): destination on left
cc/list/mach (vax/vms): destination on right
gcc output (alpha linux): destination on left
Looking at the opcodes as presented in the PDD, they're hauntingly like
the alpha codes (maybe Dan's favorite isn't the vax, but the alpha :)
If I hadn't let my hobbyist licenses expire on my vms/alpha machine, I'd
check it too...
> BW> =item eqv tx, ty, tz *
>
> BW> Bitwise Equivalence all bits in y with z and store the result in
> BW> register x.
> BW> [do we really need this one? BASIC has it, but I don't know if I've
> BW> ever found a use for it. Its (p&q)|(!p&!q), I think]
>
> that is just !(y xor z). we can provide the op but perl as we know it
> has no operator that will map to it. maybe another front end would want
> it so let's have it. it is trivial to code up and won't take any space.
>
> BW> =item imp tx, ty, tz *
>
> BW> Bitwise Implication (of) all bits in y with z and store the result in
> BW> register x. [another questionable one. Again, its a BASIC thing. The
> BW> boolean expression for it is (!p&!q)|q ]
>
> wow, that is the old boolean 'if' (if p then q) operator. i have never
> seen that needed. let the coder do it themselves at the language level.
>
I agree with not including these two, but they were ones that I
remembered having in BASIC from many moons ago.
> BW> =item rol tx, ty, tz *
>
> BW> Roll y left z bits and store the result in x.
> BW> [what are the valid values for z?]
>
> isn't that rotate left? rotate should require z to be the word size or
> less. or we can define it to work modulo the word size. which reminds
> me, is there going to be a simple language way to get the word size
> (other than %Config)?
Yep, rotate. I really need to wake up before I post email. Well, what
if a PMC or Numeric registers are passed to rol, rol, shr, shl? What
would be the size then? We could disallow them since they really don't
make sense...or do they? Is the VM going go have a fixed size register
set regardless of platform? If not, then the shift will behave
differently on each platform the bytecode is run...and that's bad,
especially if someone (cleverly) decides that a "SHL I0,I0,32" clears
the register.
>
> BW> =item shl tx, ty, tz *
>
> BW> Shift y left z bits and store the result in x. (x = y << z)
> BW> [what are the valid values of z?]
>
> is 0 shifted in from the right?
>
I would assume so, since that's the usual behavior.
>
> why the abbreviated op names? we don't want another creat(2)
> controversy. :) i don't think we need to limit our op code names to any
> length. old assemblers did so because of the odd speed up tricks. since
> the parrot assembler will rarely be used directly and it will be written
> in perl. shift_l is clearer. but then, i and many others learned short
> assembler op names without trouble. we should have some consensus on op
> name styles. underscores? longer names encouraged? etc.
>
Honestly I pulled the mneumonics from the x86 set, though the ROL/ROR
ops are the same as m68k.
>
> BW> =item shr tx, ty ,tz *
>
> BW> Shift y right z bits and store the result in y. (x = y >> z)
> BW> [what are the valid values of z?]
>
> arithemetic or logical shift? does the sign bit propogate down?
>
Beats me. I was just thinking of the args as n-bit unsigned numbers.
> BW> =item xor tx, ty, tz *
>
> BW> Bitwise Exclusive-Or of all bits in y with z and store the result in
> BW> register x. (x = y ^ z)
>
> should be near eqv as it is just its negation.
>
I just put them in alphabetical order, as that was the easiest :) Of
course, if its name becomes "EOR" (as in m68k & 6502) then
alphabetically it is right there :)
Brian
> uri
>
