You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
p. 3 para -1 says that an $int$ in $\mathcal{L}_{int}$ is a 63-bit signed integer.
In fact, AFAICT all the assembly code generated prior to Ch. 10 assumes 64-bit signed integers.
Python actually does not parse a leading '-' as part of an integer (it parses as a unary negation even if there is no separating space), so in the concrete syntax of $\mathcal{L}_{int}$ , $int$ should really be a positive integer only. (I guess after, e.g., partial evaluation, we need the abstract syntax to be able to store a signed int.) This is a small point, but may confuse students.
More seriously, none of the support code (quoted in the book or otherwise) actually performs machine arithmetic (modulo $2^{64}$) on the source language or in the X86 interpreter. This really undercuts the nice diagram (1.8)! At the very least, this deviation deserves a footnote of explanation. I also have patches that provide a small set of utility routines for doing machine arithmetic in Python and invoking them from the interpreters, checkers, and the input_int routine (which should clamp to machine range in order to match the behavior of scanf in runtime.c).
The text was updated successfully, but these errors were encountered:
p. 3 para -1 says that an$int$ in $\mathcal{L}_{int}$ is a 63-bit signed integer.
In fact, AFAICT all the assembly code generated prior to Ch. 10 assumes 64-bit signed integers.
Python actually does not parse a leading '-' as part of an integer (it parses as a unary negation even if there is no separating space), so in the concrete syntax of$\mathcal{L}_{int}$ , $int$ should really be a positive integer only. (I guess after, e.g., partial evaluation, we need the abstract syntax to be able to store a signed int.) This is a small point, but may confuse students.
More seriously, none of the support code (quoted in the book or otherwise) actually performs machine arithmetic (modulo$2^{64}$ ) on the source language or in the X86 interpreter. This really undercuts the nice diagram (1.8)! At the very least, this deviation deserves a footnote of explanation. I also have patches that provide a small set of utility routines for doing machine arithmetic in Python and invoking them from the interpreters, checkers, and the
input_int
routine (which should clamp to machine range in order to match the behavior of scanf in runtime.c).The text was updated successfully, but these errors were encountered: