Closed TAdev0 closed 3 months ago
UsortBody hint includes the following python code:
UsortBody
input_ptr = ids.input .... for i in range(input_len): val = memory[input_ptr + i] ....
Our current implementation does:
inputBasePtr, err := hinter.ResolveAsAddress(vm, input) ... for i := uint64(0); i < inputLenValue; i++ { val, err := vm.Memory.ReadFromAddressAsElement(inputBasePtr) ....
The problem is that memory[x] python code refers to the value at offset x on the execution segment.
memory[x]
x
Currently, our implementation actually does val =ids.input_ptr (+i) , which is not the expected behaviour.
val =ids.input_ptr (+i)
inputBasePtr should be resolved as felt and used to specify an offset and read at that offset.
inputBasePtr
felt
To confirm this, we can see that the AddressAp function in vm.go does the following:
AddressAp
func (ctx *Context) AddressAp() mem.MemoryAddress { return mem.MemoryAddress{SegmentIndex: ExecutionSegment, Offset: ctx.Ap} }
so basically, when the hint includes memory[ap] , we read (or write) at offset ap in the memory segment.
memory[ap]
ap
UsortBody
hint includes the following python code:Our current implementation does:
The problem is that
memory[x]
python code refers to the value at offsetx
on the execution segment.Currently, our implementation actually does
val =ids.input_ptr (+i)
, which is not the expected behaviour.inputBasePtr
should be resolved asfelt
and used to specify an offset and read at that offset.To confirm this, we can see that the
AddressAp
function in vm.go does the following:so basically, when the hint includes
memory[ap]
, we read (or write) at offsetap
in the memory segment.