-
Notifications
You must be signed in to change notification settings - Fork 9
Limits for p
operation
#33
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
Comments
The reference interpreter will store the value as a signed char, i.e. -95, but there is a wide variation in behaviour by other interpreters. Some use signed values, some use unsigned, and they can range from 8 bits to unbounded. |
Thanks for the clarification. I'm guessing it's not against the specification to use a |
The specification just refers to the playfield cells as "characters", which leaves some room for interpretation, but a signed long seems a bit of a stretch. Also, speaking as a Befunge programmer, I personally prefer interpreters that match the behaviour of the reference interpreter exactly, since it makes it easier to write portable code. That said, nobody is going to stop you doing things your own way. Plenty of other interpreters have done the same thing. Just bear in mind that your interpreter may then not be able to run some Befunge code that relies on the reference behaviour. As a compromise, you could always have an option in your interpreter to be more standard compliant. |
That's a good idea. I'll add a command line switch to disable all custom features (I've added a few instructions, such as a primitive jump that I'll also disable). |
It is unclear from what I have read what the limits of the
p
operation are, e.g. this program:99*:*66p
Does it store 6561 or whatever (signed char)6561 is?
The text was updated successfully, but these errors were encountered: