how to get rid of alisp?

[elsbiet]

because i am afraid i will soon run out of memory on my esp32 i would like to know how i can remove alisp (i don't need it).

[petermm]

I think you do it here: https://github.com/atomvm/AtomVM/blob/8eae9576c7a010ed6ad77cbc48411dabbba0818a/libs/CMakeLists.txt#L31

I doubt removing it has much impact on memory, but let us know..

[elsbiet]

after setting

set(ATOMVM_LIBS eavmlib estdlib)

and even after

idf.py clean

the alisp code did not disappear.

did i miss anything?

[petermm]

atomvmlib is built in the AtomVM/build folder see https://www.atomvm.net/doc/main/build-instructions.html#generic-unix-build-instructions

[bettio]

Are you worried about available RAM memory?

[elsbiet]

@peterman: finally i managed to get rid of alisp - edited AtomVMlibs/esp32boot/CMakeLists.txt removed it from pack_runnable(esp32boot esp32init esp32devmode eavmlib estdlib alisp)

it was kind of time consuming and painful because the docu seems to be somewhat outdated/inconsistent. removing alisp saved appr 12k which is around 5.3%.

@bettio: i'm worried about both ram and flash. i think there is an esp32-s3 - with more ram/flash but i'm not sure if and how this extended resources are supported by atomvm.

[UncleGrumpy]

Removing alisp only saves space in the library partition, so unless you are also changing the application partition beginning (and use this offset for all of the tooling — rebar3 or mix) this will not give you any more available space for your application. If your application is already too big for the default 1M application partition there is actually unclaimed flash space available at the end of the flash. You can simply remove the size parameter from the main partition In partitions.csv (since it is last in the partition table) and it will give you all of the available space for your application.

[elsbiet]

@UncleGrumpy: thank you very much for your explanation.Things become clearer.

another question: it seems to be usefull (reduced upload time) for me to put parts (parts, i assume to be stable) of my application into boot.avm/lib.avm (btw: is it possible to rename the partitions at will or can this lead to problems?). i assume that it might be necessary to enlarge the partition boot.avm and adjust the offset of main.avm. in addition, the offset in {atomvm_rebar3_plugin, [ {esp32_flash, [ {offset, NewOffset}, .. ]}} must be adjusted accordingly.

Is there anything else to consider?

[pguyot]

You can have only two partitions (in addition to nvs and phy_init): one for the VM and one for Erlang/Elixir/Gleam code.

In this case, the AVM you flash on the second partition must include libs such as eavmlib and estdlib. This is typically done with packbeam -p. packbeam can also prune unreferenced modules. Use this with caution as a module only referenced with list_to_atom will be pruned.

This is what is done with La Machine to use as much flash as possible. Likewise, I trimmed down VM by disabling drivers I don't need.

https://github.com/pguyot/la_machine/blob/2b334a4b1a3703a04adb952100901a044d1ce6c3/.github/workflows/build.yaml#L91

As mentioned by @UncleGrumpy you need to define partition.csv accordingly. See for example La Machine as well:

https://github.com/pguyot/la_machine/blob/main/image/partitions.csv

[elsbiet]

only 2 partitions in addition to nvs and phy_init - this kind of confuses me because Build Instructions # FlashLayout mentions and describes 3 parttions [ AtomVM virtual machine, boot.avm, main.avm] (in addition to nvs and phy_init).

is there anyone who can help clear up my confusion?

addendum: esp:partition_list()

returns

[{<<"nvs">>,1,2,36864,24576,[]}, {<<"phy_init">>,1,1,61440,4096,[]}, {<<"factory">>,0,0,65536,1835008,[]}, {<<"boot.avm">>,1,1,1900544,262144,[]}, {<<"main.avm">>,1,1,2162688,1048576,[]}]

[pguyot]

Sorry for the confusion. By default there are 3+2 partitions as you describe.

However, it is possible to have only 2+2.

In the latter case, you can optimize available flash size by:

• only having libs you use
• pruning modules you don't use
• taking advantage of the free space at the end of boot partition

[elsbiet]

@pguyot thanks for clarification.