Are there too many OpCall here?

[zhuliquan]

I find there are many type of OpCall OpCode in below code.

expr/vm/opcodes.go

Lines 55 to 59 in 7772ea0

	OpCall0
	OpCall1
	OpCall2
	OpCall3
	OpCallN

I read the code of cmpiler.go as below:

expr/compiler/compiler.go

Lines 157 to 171 in 7772ea0

	func (c *compiler) emitFunction(fn *builtin.Function, argsLen int) {
	switch argsLen {
	case 0:
	c.emit(OpCall0, c.addFunction(fn.Name, fn.Func))
	case 1:
	c.emit(OpCall1, c.addFunction(fn.Name, fn.Func))
	case 2:
	c.emit(OpCall2, c.addFunction(fn.Name, fn.Func))
	case 3:
	c.emit(OpCall3, c.addFunction(fn.Name, fn.Func))
	default:
	c.emit(OpLoadFunc, c.addFunction(fn.Name, fn.Func))
	c.emit(OpCallN, argsLen)
	}
	}

I got that you want to generate special bytecode based on the number of arguments of the function. However, OpCallN is also can cover the OpCall0 to the OpCall3. Now, is it a reasonable choice to delete those OpCode (i.e. OpCall0 to OpCall3) now?

[antonmedv]

All of those opcodes are needed. OpCall1-3 is a special fast call type. OpCallN is a generic fallback.