Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consideration for expanding logicalBinaryOp definition #54

Open
nilslice opened this issue Mar 14, 2022 · 1 comment
Open

Consideration for expanding logicalBinaryOp definition #54

nilslice opened this issue Mar 14, 2022 · 1 comment

Comments

@nilslice
Copy link

While working on a parser implementation in quil-rust, it struck me that the INT alternative of the right-hand operand in a logical binary operation could possibly be further specified & wanted to get some thoughts. For reference:

logicalBinaryOp     : ( AND | OR | IOR | XOR ) addr ( addr | INT ) ;
// ...
INT                 : [0-9]+ ;
  1. Is it reasonable to introduce a BIT definition which would reduce the range of values to 1 or 0? @kalzoo mentioned we can (maybe already do?) coerce an INT when needed so maybe this isn't necessary.
  2. Is there a case for parsing an expression in this position?
@stylewarning
Copy link
Member

The original reason for not allowing INTEGER values there is because different implementations of Quil might represent integers in different ways. For example, different schemes for signed fixed-precision numbers. I didn't want to require any specific width or bit-layout to integers.

There is a way in Quil to allow for this implementation-dependent behavior though; it's to use octet aliasing. Assuming INTEGER values are 16-bit unsigned integers, one could do:

DECLARE xs OCTET[2]
DECLARE ys OCTET[2]
DECLARE x INTEGER SHARING xs
DECLARE y INTEGER SHARING ys

AND xs[0] xs[0] ys[0]
AND xs[1] xs[1] ys[1]

This would be the C equivalent of

uint16_t x, y;
x &= y;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants