Viper compiler documentation?

[SteKme]

Hi,

please is there any documentation on viper compiler aside of this very short text?
https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html#the-viper-code-emitter

Some examples available perhaps? I can't find much no matter how hard I google, unfortunately.

Also, calling this viper function from other, either plain or native compiled python - is there an extra overhead when doing so, i.e. is py>viper>py set of function calls more cpu costly than calling py>py>py functions? (this is to understand if viper is meaningful for even rather short pieces of code, or pays off only for code that is executed for a longer time)... reminds me of NUMBA for cpython, where this context switching from PY to Numba function is pretty costly if I remember this right.

Thanks so much in advance,
Stepan

[scruss]

That's pretty much it, I'm afraid. There are a couple of slightly helpful threads on the old forum:

• how to use viper decorator? - MicroPython Forum (Archive)
• Supplying Arguments to viper function - MicroPython Forum (Archive)

I don't use it, since it's not available on all of the boards I use (such as esp32c3)

[rkompass]

This discussion has some nice CRC viper code (together with @asm_thumb) together with benchmarks.

A google search for "micropython viper examples" spit out: this and this.
Within the codebase there are several instructive tests of viper functionality here.

The overhead py>viper>py is there, so only lengthy calculations really benefit from viper.
Viper is improved from time to time. There was a 4 arguments limit, that is gone now, recenty unary - was added iirc.
Floating point calculations are not possible from within viper, at least atm. However you may compare (and sort) floating point numbers, I had an announcement discussion with code for that.

As Steward (@scruss) told viper is not implemented on all architectures. On the RISC one of esp32c series obviously not yet.

[peterhinch]

See also this and this - old posts that still provide interesting background.

[bixb922]

Calling a viper function seems to have similar overhead as a MicroPython function. If it has to be very fast, it would be best to minimize calls. Additional arguments seem to have little overhead.

Here are some results I found by trying out viper code, but I don't have access to more documentation, so I may be wrong on some points. My tests were on a ESP32 and ESP32-S3, I don't know if everything applies to all ports.

It seems that viper really shines with integer variables (32 bits, 16 bits and 8 bits). All int variables in viper code are of the ``viper intdata type, which is different from thebuiltins.int` datatype (i.e the MicroPython int we all know and love). Unlike `builtins.int`, viper `int` does not check for overflow, and all operations are compiled to very fast machine code.

I believe it's best to be aware at all times that viper int and builtins.int are different data types. In a viper function int() will cast or convert the argument to a viper int. For example: the error message ViperTypeError: can't do binary op between 'int' and 'object' means: there is a viper int and an object (a float, or a builtins.int, or other object) and viper does not know how to do the operation. To solve that problem, you need to do an explicit cast to a viper int with the int() function. It's not necessary to cast integer constants, they are recognized as viper int.

For the viper compiler, it's best to declare all variables explicitly, same with parameters and the return type. You declare viper int with type hints, for example:

@micropython.viper
def myfunction(a:int)->float:
    j:int 
    x:int = 1
    return 1.0

When you pass an array.array("I", ...) to a viper function, you can receive that with a viper ptr32, which is a pointer to the memory of the array. Pointers are like C pointers in that they are very fast, but you get no bounds checking. This enables to write stuff like this:

from array import array
from uctypes import addressof

@micropython.viper
def myfun(b:ptr32)->int:
    a = array("i", (11,22,33,44))
    # Edit: this is slow: x:ptr32 = ptr32(addressof(a))
    # Edit: this is better:
    x:ptr32 = ptr32(a)
    j:int = 0
    s:int = 0
    while j < 4:
        s += x[j] + b[j]
        j += 1
    return s
b = array("i", (55,66,77,88))
print(myfun(b))

Viper ptrs can be cast to a uint and back to ptr32 and you can do pointer arithmetic. For example:

    a = array("i", (11,22,33,44))
    len_of_array:int = 4
    x:ptr32 = ptr32(addressof(a))
    pointer_to_second_half_of_a: ptr32 = ptr32(uint(x) + (int(len(a))//2)*4 )

(edit) x:ptr32 = ptr32(addressof(a))can be shortened to ``ptr32(a)```. The latter is faster. Sorry about the confusion.

Note that since the array element length is 4 bytes, you have to multiply by 4 yourself.
In C, the value at the pointer is *p, in viper it's p[0]. Also note that len(a) needs to be cast to a viper int since len() returns a builtins.int. Certainly pointer arithmetic can lock up the microcontroller (nothing that a reset does not recover) and the code does not look very nice, but can be fast.

Reading and writing memory addresses directly also enables some very fast stuff with GPIO registers or other I/O functions.

range() does work under viper, so you could write: '''for x in range(10)``` but it's faster to use a while loop:

    j:int = start
    while j < limit:
           ...loop body....
        j += step

Viper ptr16 is a pointer to a unsigned 2 byte integer, i.e. you can manipulate a array.array("H", ...). Viper ptr8is a pointer to an unsigned 1 byte integer, i.e. you can manipulate a bytearray. Again, no overflow nor bounds checking.

Somewhere the docs state a maximum of 4 arguments for a viper function, that seems not to be a restriction anymore.

Just for fun, I wrote an integer FFT in viper code, see here: https://github.com/bixb922/crank-organ/blob/main/src/fft_int.py, as a longer and real example of viper code. The original C code is still there and commented, so you can compare viper to C. It takes a bit less than 30 milliseconds for 1024 data points, compared with 115 milliseconds of a @micropython.native version and about 320 milliseconds of a simple and straightforward algorithm in plain MicroPython. Please note: if you really want to do FFT, use ulab, which can do FFT at least 10 times faster than my viper code (probably with a better algorithm, too!). See https://github.com/v923z/micropython-ulab

Please correct me if something is wrong. I love to learn something new.

[rkompass]

Nice,

you need to do an explicit cast to a viper int with the int() function

I'm not sure you noted that for that explicit cast the MP int has to be a small int, i.e. has to be < 0x80000000 iirc. So a bit of trickery is involved if you want to handle integers/adresses above that.

Viper functions can be closures, but there was a problem... You may search MPs issues for viper to find that.

If you like to write that up for the docs?

Currently we learn mostly from code examples. I started with Peters LCD driver code examples, btw.

[bixb922]

for that explicit cast the MP int has to be a small int

No, I wasn't aware of that. I just tested that and interestingly, viper int(large_integer_number) just gets the last 4 bytes of the number. If the most significant bit of that is on, then the result will be negative (unlike python &).

Viper functions can be closures, but there was a problem.

Ahh, now I found #8086, interesting!

If you like to write that up for the docs?

I'll be glad if this can be of any help. Perhaps for the wiki? In that case I'd like all the feedback possible to complete this a bit.

[rkompass]

viper int(large_integer_number) just gets the last 4 bytes of the number. If the most significant bit of that is on, then the result will be negative (unlike python &).

This lead to an error report last year. But Damien is improving things sometimes and I (we) don't notice.

[SteKme]

@bixb922 - Your post above should be made sticky, awarded a zillion stars, sir! :) It alone tells more than all other texts available so far!

To have a complete information for everyone here, would You comment on the below, pleasea?

1/ ptr32: what if say 0xFFFFFF00 is stored in the array: uint(x[0]) will recover this uint, right? I mean - the array can be created as 'L' instead of 'l', but viper doesn't have such information, gets just one plain ptr32.

2/ ptr8 and ptr16. When 1 or 2 byte array is accessed, it outputs int?
x:ptr8 = ptr8(addressof(array))
a=x[0]

then a outputs 32bit int that can be later cast to uint?
-- So for one byte array items, uint(x[0]) outputs int in range 0..255 and
-- x[0] outputs int in range -128..+127?

3/ ptr8 or ptr16 - opposite, assign to the array -
x[0]=a

a is to be int or uint I guess - or what other viper type? Just least significant bytes taken from the variable get copied to the array's item, or..? (and again, how short int/short uint get treated in this assignment..)

Thank You so much to everyone involved in this thread once again, very helpful!

---

Btw - this ulab is an incredible effort as well, just a missing floating point unit of RP2040 I prefer to use due to PIO units limits its use quite a bit; still, amazing to have numerical optimization and such available on microcontroller!

[bixb922]

I hope it helps, I am sometimes unsure myself if I observed correctly :-)

int, uint, ptr32, ptr16 and ptr8 are much like casts in the C language.

• int(n) and ptr32(array)[0] return a signed 32 bit viper int
• uint(n), ptr16(array)[0] and ptr8(array)[0] return a unsigned 32 bit viper int

1/ ptr32: what if say 0xFFFFFF00 is stored in the array...

Yes, ptr32 will return the first 4 bytes interpreted as an unsigned int, whatever the memory at ptr32 holds, be it a byte array or a 32 bit signed array. No conversion is done. The int() and uint() are just a cast, they just slam the viper data type on the 4 bytes.

2/ ptr8 and ptr16. When 1 or 2 byte array is accessed, it outputs int?

Both return a 32 bit unsigned int (a viper uint). In the example, x[0] will always be 0-255.

x:ptr8 = ptr8(addressof(array))

This also can be written as x:ptr8 = ptr8(array), it's equivalent and faster. I'm sorry about the error in my previous post.

3/ ptr8 or ptr16 - opposite, assign to the array - x[0]=a
a has to be uint or int. For ptr8, the least significant byte of a gets extracted and put into x[0]. For ptr16, it's the least significant two bytes.

Again, it helps thinking about viper in terms of equivalence to the C language, much of viper is modeled after C.

[rkompass]

2/ ptr8 and ptr16. When 1 or 2 byte array is accessed, it outputs int?

Both return a 32 bit unsigned int (a viper uint). In the example, x[0] will always be 0-255.

My understanding is that it outputs int, but it's like taking a cast via an unsigned int. Simpler formulated: The bits are taken as they are (and filled to the left with 0s). No effort is made as to evaluate any sign bits and transform them into a new representation.

uint is just a cosmetic/modification for interfacing with python in function arguments and return values.
I would not trust it's functionality fully.
It would be nice to have a demonstration script for this, covering all variable exchanges through viper function parameters or return values as well as cross-type variable assignments (from python integer to viper integer, signed or unsigned, or from viper to python global or nonlocal (the latter not working, see #8086) ) within a viper function.

[bixb922]

ptr32, ptr16 and ptr8 results:
I tested that now, and yes, you are right: ptr32, ptr16 and ptr8 return a viper 32 bit signed int. They take 4, 2 and 1 byte respectively and stuff that into the signed int, leading zeros are left 0. For example, ptr8 returns values from 0 to 255.

I tested many combinations of int, uint, parameters, etc, but it is probably of interest to make that a bit more formal and complete. Will try to come up with something.

I thought uint was for memory addresses?

BTW uint does not support integer division // nor module %. And viper signed int does not exponentiation **.

I saw #8086 and there is yet another workaround possible for nonlocal, I posted it there.

[SteKme]

I wonder - call a viper function B from another viper function A, my question is regarding return types:

Let's say both A and B are coded as (both are vipers):
@native.viper
def A(a,b) -> int:

and inside A, I call B: ret=B()

The question is - it seems to me that even though B has return type declared, I still needed to modify the call to B() like this, if something else didn't affect the call:
ret=int(B())
to work. Does it means viper function always returns normal uPy object, never native viper, even when calling the viper from the viper, please? (the compiler has all the knowledge of program flow and can detect viper>viper call...)
(if not mentioned in Your docs @bixb922 , please consider adding this perhaps?
Thank You!

[bixb922]

I added some description for this case.

The static analysis is function by function, so no static information is carried over from one viper function to another.

For the caller, the viper function looks like any other MicroPython function. Return values are converted to MicroPython objects. You are correct, you need to do return int(B())

[bixb922]

I wrote all what I could find on the topic MicroPython viper here: https://github.com/bixb922/viper-docs

Please report any error you find or clarification that should be needed.

[andrewleech]

It'd be awesome if you wouldn't mind putting this info in the wiki? I just made a stub page here linked from the tips and tricks page:
https://github.com/micropython/micropython/wiki/Improving-performance-with-Viper-code

[rkompass]

Great work, congratulations.

[bixb922]

wiki updated. Please let me know if something should be complemented or corrected.

[peterhinch]

I think there are a couple of errors re integer sizes:

A viper int can hold values from -2**31-1 to 2**31, i.e. this is a 32 bit signed integer.

Should read -2**31 to 2**31 -1 (-0x8000_0000 to 0x7FFF_FFFF).

Viper integer constants are in the range -2**30 to 2**30-1. When you assign a viper constant to a variable, it automatically is a viper int.
Be aware: integer constants don't have the full range of values a viper int value can hold, they are signed 31 bit integers.

Is this actually correct? I would expect a 30 bit integer - i.e. a MicroPython small int. In which case the range is -2**29 to 2**29-1 (-0x2000_0000 to 0x1FFF_FFFF).

As a general point, now that the doc exists in two places, how should we issue non-contentious corrections? I've spotted a few typos - should we edit the Wiki or raise a PR?

[SteKme]

I have noticed this const issue myself - basically subtracting from max uint of 0xffffffff and const(0xffffffff) was a problem if I recall - had to avoid const and used a=uint(0xffffffff) in the code instaed.. but I kind of fought viper and really, anything else might have been a culprit, basically I tried and retried until I got this to work.

Re signed int: normally, it is -half to +half-1, at least intel world. Not sure about arm, but I'd guess the same there, indeed, so I tend to support Peter on this.

[bixb922]

I took the liberty to edit the wiki page directly. I suggest that the developers change the permissions at some point, so the wiki can be maintained via PR.

Viper int range typo corrected, should read -2**31 to 2**31 -1 now.

Small int/viper integer constant range: @peterhinch you are correct, the range is -2**29 to 2**29-1 as you point out. I corrected that in the document, please check if it's ok now.

As a general point, now that the doc exists in two places, how should we issue non-contentious corrections?

What do you mean by "two places"? If you mean my repository, I renamed it to https://github.com/bixb922/viper-examples to avoid confusions and deleted the README.md there, in order to have only one copy of the document online. I felt that it could be useful to keep the examples there online. I have been using those examples to find out how viper works.

I've spotted a few typos - should we edit the Wiki or raise a PR?

@andrewleech? I am happy to do the corrections, but for many small changes, perhaps raising a PR is simpler than explaining the changes to someone else. There is room for improvement.

[andrewleech]

I took the liberty to edit the wiki page directly. I suggest that the developers change the permissions at some point, so the wiki can be maintained via PR.

Thanks, yes that's exactly what I intended / hoped for!

In my understanding, the loose idea by the maintainers is to keep the wiki free to edit as a collaborative space for people to put down snippets of info like this.

Ideally once a page comes together well there it could be refined (via pr) into a formal docs update / page.

The wiki is currently quite disorganised though which makes it hard to know where to put stuff like this. We'd like to clean up the top level structure to make it easier to navigate and find stuff, but that's still a ways down the to-do list.

[andrewleech]

I am happy to do the corrections, but for many small changes, perhaps raising a PR is simpler than explaining the changes to someone else. There is room for improvement.

As mentioned above, if it's on the wiki please feel very free to edit / update / correct things there, all contributions welcome!

Stuff that's in the docs website, the source for that is all in the micropython repo and PR is the way to suggest updates there.

[peterhinch]

I've corrected a few typos and changed one instance of "signed 31 bit integers" to "signed 30 bit integers".

This is a seriously useful doc and has certainly given me some insights into how it works :)

[SteKme]

Hi,

one more question I struggled with a bit, please (and consider updating docs accordingly): I wonder is it possible to return just a primitive type from viper, that is int, uint? Viper requires return type precisely specified, of course..

• if an array (bytearray) gets allocated within viper, is it possible to return reference to it? (and what return type to use...)
• is it possible to return something else like None, boolean - I quite often use tristate None/True/False for state of some process (None - still in progress, or True/False = outcome of it -- of course, can use int instead) - problem is this requires 'Optional' from typing...
• what about multiple parameter return, say tuple?

I mean, a workaround surely is to prealloc some array outside of viper, pass this array to viper and use it to return values from it; but there may be some more elegant way perhaps..

Thank You so much and regards,
Stepan

[rkompass]

@SteKme I was not sure. Good questions btw.. So I tried it out.
I also tried the new feature of unary "-".
The latter is not in the docs yet (and (together with uint and ptr32 return type) also not in the very nice Wiki page by @bixb922).

Here is the code:

from array import array
from uctypes import addressof, bytes_at

# from https://github.com/orgs/micropython/discussions/14297

# 1. I wonder is it possible to return just a primitive type from viper, that is int, uint?
# 
# 2. If an array (bytearray) gets allocated within viper, is it possible to return reference to it?
#   (and what return type to use...)
#
# 3. Is it possible to return something else like None, boolean tuple?

# ----- 1. ------
@micropython.viper
def vip_in2uint(x: int) -> uint:
    return uint(x)

print(vip_in2uint(-5))    # 4294967291   <---- yes

# ----- 2. ------
@micropython.viper
def vip_retarr() -> ptr32:
    a = array('i', [5432, 1234, 0001, -2321])  # in CPython: SyntaxError: leading zeros in decimal 
    aadr = ptr32(a)       # integer literals are not permitted; use an 0o prefix for octal integers
    return aadr

adr = vip_retarr()
print(adr)               # 536967184   <---- yes
adr_bytes = bytes_at(adr, 16)
print(adr_bytes)         # b'8\x15\x00\x00\xd2\x04\x00\x00\x01\x00\x00\x00\xef\xf6\xff\xff'

                         # we have not uctypes.cast in Micropython
for i in range(4):
    print(int.from_bytes(adr_bytes[4*i:(4*i+4)], 'little'))

#   5432                 #    <--- the integers in the array
#   1234
#   1
#   4294964975           #    <--- the sign is lost (same in CPyton)

# ----- 3. ------
@micropython.viper
def vip_tuple1a():
    return (2, 3)

print(vip_tuple1a())     # (2, 3)   <---- yes

@micropython.viper
def vip_tuple1b():
    return (True, None)

print(vip_tuple1b())     # (True, None)   <---- yes


# ----- we also try out negation of integers and observe an error here -----
@micropython.viper
def vip_tuple2a():
    a:int = int(-5)
    return (a, 2)

print(vip_tuple2a())    # (-5, 2)  <---- yes

@micropython.viper
def vip_tuple2b():
    a:int = int(-5)
    return (a, -a)

print(vip_tuple2b())    # (-5, 5)  <---- yes

@micropython.viper
def vip_tuple2c():
    a:int = int(-5)
    b = -a          
    return (a, b)

print(vip_tuple2c())    # (5, 5)  <---- oops , found an error !!!!, should be (-5, 5)

@micropython.viper
def vip_tuple2d():
    a:int = int(-5)
    return (a, -a, a)

print(vip_tuple2d())    # (-5, 5, 5)  <--- error!!!!, should be (-5, 5, -5)

IIrc many of those were not possible yet recently. It seems viper is improved permanently, without much advertising.
You note the unary "-" reveals an error, if I'm not mistaken. Ill raise an issue.
Although array and tuple declarations are possible within viper, viper certainly will not execute these in its own compiled manner, but call MP functions to execute them. So do not expect a speed advantage from using these within viper.

[SteKme]

interesting, so return type isn't mandatory... I thought I had to specify one. Really, it is a bit complicated to distinguish between own errors and viper limitations, that's why Your help is very valuable!
Viper is so cool, incredibly fast for bit operations, number crunching, truly saves the day.

[rkompass]

Unary operations were introduced in 3c445f6.
And there is also unary invert. On may guess that unary invert exhibits the same erroneous behaviour and so it does:

@micropython.viper
def vip_invert() -> int:
    a = 5
    b = ~a          
    return a+b

print(vip_invert())    # -12  <---- error, should be -1

@micropython.viper
def vip_tuple_inv():
    a:int = int(5)
    b = ~a          
    return (a, b)

print(vip_tuple_inv())    # (-6, -6)  <---- error, should be (5, -6)

I updated the issue.

Once this is solved there should be noted that both unary operations are available in viper.

[bixb922]

Wiki updated, thanks for that information and the tests!

[rkompass]

Hey @bixb922,

nice.
Your improvement on the Wiki page lead me to a short inspection of the source in py/emitnative.c.

There is also the viper bool type which we haven't mentioned so far, and which is not in any docs yet, as it seems.

I made some tests:

@micropython.viper
def viptest_bool(x: int) -> bool:
    r:bool = bool(x)
    return r

print(viptest_bool(-1))           # --> True
print(viptest_bool(0))            # --> False
print(viptest_bool(True))         # --> True

# @micropython.viper
# def viptest_bool(b: bool) -> int:
#     return b                        # ViperTypeError: return expected 'int' but got 'bool'

@micropython.viper
def viptest_bool2(b: bool) -> int:
    r:int = int(b)
    return r

print(viptest_bool2(-1))          # --> 1
print(viptest_bool2(True))        # --> 1
print(viptest_bool2(False))       # --> 0


from array import array

a = array('I', (5, 2, 0))
b = array('I', (1, 2, 3))

@micropython.viper
def viptest_bool3(p: ptr32) -> bool:
    r:bool = True
    for i in range(3):
        r = r and bool(p[i])
    return r

print(viptest_bool3(a))           # --> False
print(viptest_bool3(b))           # --> True


c = array('I', (0, 2, 0))
d = array('I', (0, 0, 0))

@micropython.viper
def viptest_bool3a(p: ptr32) -> bool:
    r:bool = False
    for i in range(3):
        r = r or bool(p[i])
    return r

print(viptest_bool3a(c))          # --> True
print(viptest_bool3a(d))          # --> False

and they all seem to work as expected.

If you like to update again (more work :-( , completeness is a monster) ?
If you don't like, I'll perhaps do it in the next days.

[bixb922]

nice! I added something about bools, @rkompass thank you for reading the code and writing those examples!

Any comment is welcome!

[rkompass]

I read your changes. Fine.
Actually I think you found another bug of viper.

Similar to int() and uint(), bool() is a cast operator. If used on a viper variable, only the type is changed, no conversion takes place (similar to casting in C language).

After checking that, I find that this holds for viper, but not for C and not for Python.
So your comment is correct wrt. viper. But not wrt. C:

In C (tested with C99, C11)

#include <stdio.h>
#include <stdbool.h>

int main() {

	int x = 23;
	int y;
	bool b = (bool) x;
	y = (int) b;
	
	printf("%d, %d, %d\n", x, b, y);  // ---> 23, 1, 1
	
	return 0;
}

as indicated in the comment the cast is really a conversion of the value à la : b = x ? 1 : 0;
And so it is in Python.
Simple casting by internal assignment of the boolean type is a bug in viper:

def cast_bool1(x):
    b = bool(x)
    y = int(b)
    return y


@micropython.viper
def cast_bool2(x: int) -> int:
    b = bool(x)
    y = int(b)    # Now y holds the same value as x
    return y

x = 12345

print(x, cast_bool1(x))   # ---> 12345 1
print(x, cast_bool2(x))   # ---> 12345 12345

There is an understanding that, apart from the small int restriction (and others, and availability of pointers, of course) viper should behave like Python. Which it clearly does not do here.
Do you want to raise an issue?

[rkompass]

Any comment is welcome!

I take that serious, man:-)

So there is an addition regarding speed:

TLDR: Use a while loop instead of range() but interate the pointer directly, not the index to the pointer.

You have the first rule mentioned in the wiki, but not the second. And it's about speed.
Demonstration code (timing from 80Mhz Cortex-M3 in the w600):

from array import array
from time import ticks_us, ticks_diff

a = array('i', (2*i+1 for i in range(10000)))

@micropython.viper
def vip_add1(p: ptr32, l: int) -> int:
    r:int = 0
    for k in range(l):            # range() works, but is not fastest
        r += p[k]                 # accessing with p[i]
    return r

@micropython.viper
def vip_add2(p: ptr32, l: uint) -> int:
    r:int = 0
    k:uint = uint(0)
    while k < l:                  # a while loop is faster 
        r += p[k]                 # accessing with p[i]
        k += 1
    return r

@micropython.viper
def vip_add3(p: ptr32, l: uint) -> int:
    r:int = 0
    pstop: uint = uint(p) + 4*l
    while uint(p) < pstop:        # directly looping the pointer to the array and indexing
        r += p[0]                 # with p[0] is faster than accessing with p[i]
        p = ptr32(uint(p) + 4)    # casts necessary because the types are fixed in viper
    return r


t0 = ticks_us()
sum1 = vip_add1(a, len(a))           # --> 100000000
t1 = ticks_us()
sum2 = vip_add2(a, len(a))           # --> 100000000
t2 = ticks_us()
sum3 = vip_add3(a, len(a))           # --> 100000000
t3 = ticks_us()

print('vip_add1:', sum1, 'time:', ticks_diff(t1, t0)/10000, 'µs per it.') # --> 0.7064 µs
print('vip_and2:', sum2, 'time:', ticks_diff(t2, t1)/10000, 'µs per it.') # --> 0.5767 µs
print('vip_and3:', sum3, 'time:', ticks_diff(t3, t2)/10000, 'µs per it.') # --> 0.3635 µs

[bixb922]

Thanks for pointing that out! I updated the wiki page to make clear that C language bool is different from Viper bool.

I am unsure if this should be considered a bug. The official docs state that the Viper extensions are "not fully compliant" with Python, so I think differences have to be expected.

The only unexpected behavior here is that 'int(bool(int(x))) == x`. It is a bit unfortunate that Viper bool is different to C bool because it's easier to explain that "Viper data types are just like C data types, Viper casts are just like C casts". I am still trying to think if there is some other consequence that should be documented.

Ohh, controlling a loop with a pointer variable takes me back about 30 years.... forgot about that! Will add to the wiki page too! Thanks!

(edit) Added to the wiki page. I took the complete example of range vs while vs while+pointer arithmetic and copied it there, I hope that's ok.