ulab, or what you will - numpy on bare metal

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
v923z
Posts: 100
Joined: Mon Dec 28, 2015 6:19 pm

Re: ulab, or what you will - numpy on bare metal

Post by v923z » Tue Nov 05, 2019 7:14 am

Hi all,

I am a bit confused by the specified flash size of the D series. According to the store's web site, https://store.micropython.org/product/PYBD-SF3-W4F2, they all should have at least 2 MB flash (external, with execute capability), yet, I can't compile the firmware with ulab enabled for the SF2, and SF3. Is the 2 MB extra for the file system only? How much leeway has one for SF6?

To put the question in context, in numpy, many methods can be called in two ways. Either as a method of the ndarray, or as a function. So, e.g.,

Code: Select all

a = array([1, 2, 3, 4])
flip(a)
and

Code: Select all

a = array([1, 2, 3, 4])
a.flip()
produce the same result, except that the first creates a copy of a first, and then operates on that, while the second manipulates a in place. If flash space is very tight, I would yank all out-of-place function objects, and keep only the in-place versions. You can always do

Code: Select all

a = array([1, 2, 3, 4])
b = a
b.flip()
if you want to work on the copy.

I would like to stress that these functions/methods haven't got to be implemented twice, it is basically two ways of calling the same internal C method. But there is still an overhead, because the function objects, the QStrings, and the function wrapper are sort of duplicate. I believe, one can save a couple of kB there.

How do you feel about this issue? Can we go with the solution I outlined, or do you think that keeping both options is important?

Cheers,

Zoltán

User avatar
jimmo
Posts: 830
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: ulab, or what you will - numpy on bare metal

Post by jimmo » Tue Nov 05, 2019 7:54 am

v923z wrote:
Tue Nov 05, 2019 7:14 am
Is the 2 MB extra for the file system only? How much leeway has one for SF6?
The firmware for the sf2 and sf3 is spread across the internal flash and the external qspiflash. By default everything goes to internal, except for things explicitly mentioned in the linker script (e.g. nimble and mbedtls).

Especially on the sf2, the firmware is quite close to the limit for the internal flash. So either:
- we move some more core functionality to external (e.g. some more stuff from extmod?)
- we make user modules go in external flash by default (I'm not sure exactly off the top of my head how to specify this in the linker script but I'm sure it's doable)
- you annotate functions explicitly inside the ulab code to specify which section they should end up in. (there's an attribute you can apply to symbols)

I'll have a play around later and get back to you.

Either way, this can definitely be made to work, no need to cut down useful functionality. (Although maybe making it a configuration option is still worth doing for other more constrained boards).

User avatar
jimmo
Posts: 830
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: ulab, or what you will - numpy on bare metal

Post by jimmo » Tue Nov 05, 2019 7:56 am

I should add, on SF6 the external qspiflash is currently unused for storing code as the main firmware fits entirely in internal flash.

Post Reply