How do I get the address of a function?

[cve2022]

Say:

def some_function():
    pass

>>> some_function
<function some_function at 0x200082f0>

Is the above the physical address of the function or it is the address of the object? If the latter, is there a way to retrieve the physical address of the function itself?

[stinos]

Can you explain what you want to achieve? That number is a C memory address, which isn't going to be of much use in Python.

[cve2022]

Hello, @rkompass , thank you for the reference. I will carefully read it.

FWIW, I was trying to emulate the irq_set_exclusive_handler() function of Pico's SDK. I was writing the code below when it occurred to me I was going to pass the function object address, not the address of the function that effectively executes the ISR. Another thing that occurred to me AFTER starting this thread is some_function() as in my OP is MP bytecode, so things are even more complicated than I initially thought.

The code below contains the first functions I coded but it also prints some data that gave me a few hints on the interrupt system contents.

from micropython import const
from machine import mem32, disable_irq, enable_irq

PPB_BASE = const(0xE0000000)
ICSR = const (PPB_BASE + 0xED04)
VTOR = const (PPB_BASE + 0xED08)
NVIC_ISER = const (PPB_BASE + 0xE100)
NVIC_ICER = const (PPB_BASE + 0xE180)
NVIC_ISPR = const (PPB_BASE + 0xE200)
NVIC_ICPR = const (PPB_BASE + 0xE280)
NVIC_IPR0 = const (PPB_BASE + 0xE400)
NVIC_IPR1 = const (PPB_BASE + 0xE404)
NVIC_IPR2 = const (PPB_BASE + 0xE408)
NVIC_IPR3 = const (PPB_BASE + 0xE40C)
NVIC_IPR4 = const (PPB_BASE + 0xE410)
NVIC_IPR5 = const (PPB_BASE + 0xE414)
NVIC_IPR6 = const (PPB_BASE + 0xE418)
NVIC_IPR7 = const (PPB_BASE + 0xE41C)

NUM_IRQS = const (32)

def _check_irq_param(num):
    if not type(num) == 'int' or num >= NUM_IRQS:
        raise ValueError('Invalid num argument {} {}'.format(type(num), num))

def _check_irq_hdlr_type(irq_hdlr):
    if not type(irq_hdlr) == 'function':
        raise TypeError ('irq_hdlr not a function')

def _check_irq_free (num):
    irqs = mem32[NVIC_ISER]
    if irqs & (1<<num):
        raise ValueError('IRQ already in use: {}'.format(num))

def set_exclusive_handler(num, irq_hdlr):
    _check_irq_param(num)
    _check_irq_hdlr_type(irq_hdlr)
    state = disable_irq()
    _check_irq_free(num)
    enable_irq(state)

if __name__ == '__main__':
    NVIC_LIST = const ((
        'NVIC_ISER', 'NVIC_ICER', 'NVIC_ISPR', 'NVIC_ICPR',
        'NVIC_IPR0', 'NVIC_IPR1', 'NVIC_IPR2', 'NVIC_IPR3', 'NVIC_IPR4',
        'NVIC_IPR5', 'NVIC_IPR6', 'NVIC_IPR7', 'ICSR', 'VTOR',
    ))
    INTR_LIST = const ((
        'TIMER_IRQ_0  ', 'TIMER_IRQ_1  ', 'TIMER_IRQ_2  ', 'TIMER_IRQ_3  ',
        'PWM_IRQ_WRAP ', 'USBCTRL_IRQ  ', 'XIP_IRQ      ', 'PIO0_IRQ_0   ',
        'PIO0_IRQ_1   ', 'PIO1_IRQ_0   ', 'PIO1_IRQ_1   ', 'DMA_IRQ_0    ',
        'DMA_IRQ_1    ', 'IO_IRQ_BANK0 ', 'IO_IRQ_QSPI  ', 'SIO_IRQ_PROC0',
        'SIO_IRQ_PROC1', 'CLOCKS_IRQ   ', 'SPI0_IRQ     ', 'SPI1_IRQ     ',
        'UART0_IRQ    ', 'UART1_IRQ    ', 'ADC_IRQ_FIFO ', 'I2C0_IRQ     ',
        'I2C1_IRQ     ', 'RTC_IRQ      ',
    ))

    print ("NVIC registers")
    for i in NVIC_LIST:
        v = eval(i)
        x= mem32[v] & 0xFFFFFFFF
        print (i + '-> ' + '0x%08X'% (v) + ': ' + '0x%08x'% (x))

    int_base = mem32[eval("VTOR")]
    print ("\nInt Vector Table. VTOR = " + hex(int_base))
    print ("i = range(0:16) -> ARM's vectors (reset, exceptions etc.)")
    print ("i = range(16:42) -> RP2's interrupts (timers etc.)")

    for i in range(0,42):
        v = int_base + i*4;
        x= mem32[v] & 0xFFFFFFFF
        t = INTR_LIST[i-16] if i >= 16 else ''
        print ('INTRPT: ' + str(i) + '[' + t + '] -> ' + '0x%08X'% (v) + ': ' + '0x%08X'% (x))

Function set_exclusive_handler(num, irq_hdlr) is incomplete, exactly because I realized the issues aforementioned.

Below is the result of the run. Not all interrupts are enabled during the execution per NVIC_ISER content (oddly, that is the case of the USB) and most vectors from 16 upwards are set to the default handler, including TIMER_IRQ_0 to TIMER_IRQ_2.

NVIC registers
NVIC_ISER-> 0xE000E100: 0x0000a028
NVIC_ICER-> 0xE000E180: 0x0000a028
NVIC_ISPR-> 0xE000E200: 0x00010040
NVIC_ICPR-> 0xE000E280: 0x00010040
NVIC_IPR0-> 0xE000E400: 0x80808080
NVIC_IPR1-> 0xE000E404: 0x80808080
NVIC_IPR2-> 0xE000E408: 0x80808080
NVIC_IPR3-> 0xE000E40C: 0x80808080
NVIC_IPR4-> 0xE000E410: 0x80808080
NVIC_IPR5-> 0xE000E414: 0x80808080
NVIC_IPR6-> 0xE000E418: 0x80808080
NVIC_IPR7-> 0xE000E41C: 0x80808080
ICSR-> 0xE000ED04: 0x00400000
VTOR-> 0xE000ED08: 0x20000000

Int Vector Table. VTOR = 0x20000000
i = range(0:16) -> ARM's vectors (reset, exceptions etc.)
i = range(16:42) -> RP2's interrupts (timers etc.)
INTRPT: 0[] -> 0x20000000: 0x20042000
INTRPT: 1[] -> 0x20000004: 0x100001F7
INTRPT: 2[] -> 0x20000008: 0x100001C3
INTRPT: 3[] -> 0x2000000C: 0x100001C5
INTRPT: 4[] -> 0x20000010: 0x100001C1
INTRPT: 5[] -> 0x20000014: 0x100001C1
INTRPT: 6[] -> 0x20000018: 0x100001C1
INTRPT: 7[] -> 0x2000001C: 0x100001C1
INTRPT: 8[] -> 0x20000020: 0x100001C1
INTRPT: 9[] -> 0x20000024: 0x100001C1
INTRPT: 10[] -> 0x20000028: 0x100001C1
INTRPT: 11[] -> 0x2000002C: 0x100001C7
INTRPT: 12[] -> 0x20000030: 0x100001C1
INTRPT: 13[] -> 0x20000034: 0x100001C1
INTRPT: 14[] -> 0x20000038: 0x10029C5D
INTRPT: 15[] -> 0x2000003C: 0x100001CB
INTRPT: 16[TIMER_IRQ_0  ] -> 0x20000040: 0x100001CD
INTRPT: 17[TIMER_IRQ_1  ] -> 0x20000044: 0x100001CD
INTRPT: 18[TIMER_IRQ_2  ] -> 0x20000048: 0x100001CD
INTRPT: 19[TIMER_IRQ_3  ] -> 0x2000004C: 0x1002C891
INTRPT: 20[PWM_IRQ_WRAP ] -> 0x20000050: 0x100001CD
INTRPT: 21[USBCTRL_IRQ  ] -> 0x20000054: 0x20005B2D
INTRPT: 22[XIP_IRQ      ] -> 0x20000058: 0x100001CD
INTRPT: 23[PIO0_IRQ_0   ] -> 0x2000005C: 0x10029F4D
INTRPT: 24[PIO0_IRQ_1   ] -> 0x20000060: 0x100001CD
INTRPT: 25[PIO1_IRQ_0   ] -> 0x20000064: 0x10029F3D
INTRPT: 26[PIO1_IRQ_1   ] -> 0x20000068: 0x100001CD
INTRPT: 27[DMA_IRQ_0    ] -> 0x2000006C: 0x100001CD
INTRPT: 28[DMA_IRQ_1    ] -> 0x20000070: 0x100001CD
INTRPT: 29[IO_IRQ_BANK0 ] -> 0x20000074: 0x20005B39
INTRPT: 30[IO_IRQ_QSPI  ] -> 0x20000078: 0x100001CD
INTRPT: 31[SIO_IRQ_PROC0] -> 0x2000007C: 0x20000561
INTRPT: 32[SIO_IRQ_PROC1] -> 0x20000080: 0x100001CD
INTRPT: 33[CLOCKS_IRQ   ] -> 0x20000084: 0x100001CD
INTRPT: 34[SPI0_IRQ     ] -> 0x20000088: 0x100001CD
INTRPT: 35[SPI1_IRQ     ] -> 0x2000008C: 0x100001CD
INTRPT: 36[UART0_IRQ    ] -> 0x20000090: 0x100001CD
INTRPT: 37[UART1_IRQ    ] -> 0x20000094: 0x100001CD
INTRPT: 38[ADC_IRQ_FIFO ] -> 0x20000098: 0x100001CD
INTRPT: 39[I2C0_IRQ     ] -> 0x2000009C: 0x100001CD
INTRPT: 40[I2C1_IRQ     ] -> 0x200000A0: 0x100001CD
INTRPT: 41[RTC_IRQ      ] -> 0x200000A4: 0x100001CD

[cve2022]

Perhaps the inspect function at #9784 is helpful.

It turns out it may be helpful, yes. Results for the functions I used to test below.

Using viper or machine code solves one of the issues I mentioned above. Maybe, all the issues.

One question, what format does the 'O' argument correspond to?

@micropython.viper
def fn_viper():
    pass

@micropython.asm_thumb
def fn_asm():
    nop()

>>> inspect(fn_viper)
viper function object at: 0x200082f0
number of args: 0
machine code at: 0x20009330
-- code --
f2b54768ff687f69084611461e46002900d003e00022904200d104e000223b463433db6f98473868ffe7f2bd
----------

F2 B5    push {r1, r4, r5, r6, r7, lr}
47 68    ldr  r7, [r0, #4]
FF 68    ldr  r7, [r7, #0xc]
7F 69    ldr  r7, [r7, #0x14]
08 46    mov  r0, r1
11 46    mov  r1, r2
1E 46    mov  r6, r3
00 29    cmp  r1, #0
00 D0    beq  #0x20009344
03 E0    b    #0x2000934c
00 22    movs r2, #0
90 42    cmp  r0, r2
00 D1    bne  #0x2000934c
04 E0    b    #0x20009356
00 22    movs r2, #0
3B 46    mov  r3, r7
34 33    adds r3, #0x34
DB 6F    ldr  r3, [r3, #0x7c]
98 47    blx  r3
38 68    ldr  r0, [r7]
FF E7    b    #0x2000935a
F2 BD    pop  {r1, r4, r5, r6, r7, pc}

>>> inspect(fn_asm)
asm_thumb function object at: 0x20008370
number of args: 0
machine code at: 0x20009190
-- code --
f2b500bff2bd
----------

F2 B5    push {r1, r4, r5, r6, r7, lr}
00 BF    nop  
F2 BD    pop  {r1, r4, r5, r6, r7, pc}

[rkompass]

One question, what format does the 'O' argument correspond to?

You refer to array.array('O', [f]) I suppose. I'm wondering myself. I did not find a documentation for that. 'O' could mean Object perhaps.

[cve2022]

One question, what format does the 'O' argument correspond to?

You refer to array.array('O', [f]) I suppose. I'm wondering myself. I did not find a documentation for that. 'O' could mean Object perhaps.

Yes. @robert-hh has found an explanation.

One question, is there a reason not to simply use inspect() id() instead?

I am a little puzzled about how this bit of the code works:

    @micropython.asm_thumb
    def dummy_asm():
        pass
    @micropython.viper
    def dummy_vip() -> int:
        return 0
    if type(f) == type(dummy_asm):
        offs = 0
    elif type(f) == type(dummy_vip):
        offs = 4
    else:
        raise ValueError('expecting an asm_thumb or viper function')

If I print the type of either dummy_asm() or dummy_vip() inside inspect(), I get 'function'. Still it works (I added prints inside the ifs).

[cve2022]

One question, is there a reason not to simply use inspect() instead?

OOPS!!! I meant id()

[robert-hh]

Looking for it in the code at py/binary.c, there are three type codes, 'P', 'O' and 'S', which have the size of a void * and are not defined otherwise in CPython. According to the comments, 'O' stand for an array of objects, 'P' for an array of pointers. No comment about 'S'.

[cve2022]

@rkompass wrote:

Perhaps the inspect function at #9784 is helpful. I adapted it from dhylands for viper and asm_thumb functions. Perhaps it could work (in modified form) for C functions too. I inspected assembler functions with it and wrote assembler functions that store data within themselfes. It should be easy to branch to C code from within asm_thumb as soon as its address is known. So how does one get the addresses of C functions? @cve2022 please keep us up to date on what you find out. How to implement an interrupt that is not accessible by standard MP classes is a very interesting (and important) topic imho.

I will mark this thread as answered by the message quoted above. I implemented a class to program the alarm interruption, using the inspect function as a basis to install a Viper handler, but MP hangs when the interrupt occurs, probably because I am calling an MP function inside the Viper handler. I need to do a small test lighting a LED (direct access to the GPIO pin with mem32 or ptr32) just to confirm it but I think I will pursue a different approach (e.g., extending the Timer class in C).