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

Part 07 precedence of comparisons #35

Open
minoring opened this issue Dec 26, 2020 · 3 comments
Open

Part 07 precedence of comparisons #35

minoring opened this issue Dec 26, 2020 · 3 comments

Comments

@minoring
Copy link

I believe the precedence of arithmetic operations must have greater value than
ones of comparison operator. (In OpPrec[])

For example, if input was,

print 1 + 2 < 4

then the output assembly is,

	.text
.LC0:
	.string	"%d\n"
printint:
	pushq	%rbp
	movq	%rsp, %rbp
	subq	$16, %rsp
	movl	%edi, -4(%rbp)
	movl	-4(%rbp), %eax
	movl	%eax, %esi
	leaq	.LC0(%rip), %rdi
	movl	$0, %eax
	call	printf@PLT
	nop
	leave
	ret

	.globl	main
	.type	main, @function
main:
	pushq	%rbp
	movq	%rsp, %rbp
	movq	$1, %r8
	movq	$2, %r9
	movq	$4, %r10
	cmpq	%r10, %r9
	setl	%r10b
	andq	$255,%r10
	addq	%r8, %r10
	movq	%r10, %rdi
	call	printint
	movl $0, %eax
	popq %rbp
	ret

As you can see, they calculate 1 + (2 < 4), not (1 + 2) < 4

@jamestjw
Copy link

I agree with your take on this, below is a snippet of operator precedence from the SubC compiler

static int Prec[] = {
	7, /* SLASH */
	7, /* STAR */
	7, /* MOD */
	6, /* PLUS */
	6, /* MINUS */
	5, /* LSHIFT */
	5, /* RSHIFT */
	4, /* GREATER */
	4, /* GTEQ */
	4, /* LESS */
	4, /* LTEQ */
	3, /* EQUAL */
	3, /* NOTEQ */
	2, /* AMPER */
	1, /* CARET */
	0, /* PIPE */
};

and indeed we can see that the comparison operators have lesser precedence than the arithmetic operators, and the equality operators have lesser precedence than the comparison operators

@mxysfive
Copy link

I also meet this problem. When I input 2 + 7 < 9 the author's code return 3 rather than 0.

@vcheckzen
Copy link

vcheckzen commented Jun 25, 2023

Yes, the author could have done the wrong thing. The precedence order is not consistent with this doc which is even mentioned by the author in Readme. In this chapter, the precedence table should be adjusted to the following.

// Operator precedence for each token. Must
// match up with the order of tokens in defs.h
// Larger ones should first be caculated.
static int OpPrec[] = {
   0,                           // T_EOF
  30, 30,                       // T_PLUS, T_MINUS
  40, 40,                       // T_STAR, T_SLASH
  10, 10,                       // T_EQ, T_NE
  20, 20, 20, 20                // T_LT, T_GT, T_LE, T_GE
};

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

4 participants