Memory footprint of autogenerated C structures

[ThibFrgsGmz]

Hi,

Please correct me if I have misunderstood the way to use ASN.1.

To serialize a message according to a uPER/ACN encoding protocol, you have to

• define a C structure of the message,
• fill it with good values,
• pass it to the encoding function to have a serialized message in the BitStream object.

This C structure of the message would be allocated at compile time in the BSS section (or on the stack like your unit tests but there is a big risk of stack overflow).

So I'm interested in the memory footprint of the structure and what I see worries me.

I see that my U8/I8/U16/I16 types are in fact asn1SccUint/asn1SccSint which are 64 bits or 32 bits depending on whether WORD_SIZE is 8.
Note: same story for F32 floats.

Could you tell me the reason why the members of C structures are 32/64 bits?

Isn't there a way to reduce their memory footprint? I mean, a U8 is an unsigned char, a U16 an unsigned short, etc.

[usr3-1415]

To be honest, there is no technical reason for using int64 or uint64 everywhere rather than smaller types based on the range. Actually, it was never requested.

We plan to support it in a future release.

[ThibFrgsGmz]

OK, no problem. As I don't see any open ticket on it, I pass the discussion as an issue. Requesters, like @RudolfGerber09, will be able to monitor the status of this feature.

[RudolfGerber09]

Hi,

we have a similar footprint issue:

Problem:
The basic ASN1 types used in the definitions are:
AsnUint32, AsnUint16, AsnUint8, AsnInt16 …..
All of them get at the end mapped to an 32 bit value. This creates much larger RAM footprint then neccessary.
e.g.:
AsnUint8 will end up into an 32 bit value while the 8 bit would be enough.

What we would like to do:
Since we have strong limitations in the RAM footprint we would like to re-define the mapping to use minimum RAM footprint.
i.e.:
AsnUint32,  keep 32 bit
AsnUint16,  map to 16 bit
AsnUint8,  map to 8 bit

• Is this possible by configuration, without affecting the functionality?
• Or can you suggest any other measure to cope with this problem?

I would appreciate a solution to this problem since we work in a very constrained environment.

[maxime-esa]

While I understand the need, please note that the impact of this feature has to be carefully evaluated:

• existing code may break if the generated types for integers depends on the range
• the runtime (check the asn1crt folder) will require some updates to cope with the new types
• both C and Ada backends will have to be updated (template files .stg in the StgC and StgAda folders)
• the ctype-based Python bindings will break and will need updates
• other tools which assume that the default type for integers is always Asn1Int / Asn1Uint will break

With this in mind, if you have a short-term need for this feature you may proceed in updating the runtime and the templates in a separate branch ; ESA will take care of the Python bindings and other tools that are under our control.
And of course we can support you with all the help you may need to find the places to update and test the modifications.

[RudolfGerber09]

Hallo Maxime,

many thanks for the respond.
I undertand, that for the near future you do not plan to do modifications related to this topic.

On the other hand with high probability we'lll require a footprint reduction.
At the same time we are at high time pressure and do not have the resources to maintain changes to the ASN1SCC source code.

Can you imagine that we could safely postprocess the generated code (e.g. using Python scripting) to use the smaller types?
Which modifications (replace patterns) we would need to apply to the generated code?

[maxime-esa]

@ThibFrgsGmz @RudolfGerber09
The feature has been implemented and merged in master branch for both Ada and C backends.

There is a new flag -slim that you can use and the tool will generate integer types that are as small as possible given the range constraint.

[RudolfGerber09]

Maxime, I just tried to find the release containing this change, but the latest release I found on https://github.com/ttsiodras/asn1scc
is 21 days old ("ACN Encoding speed improvement").

Can you please tell me where I can find the new footprint optimized version?

[maxime-esa]

@RudolfGerber09 I just added the linux binary release here: https://github.com/ttsiodras/asn1scc/releases/tag/4.3.1.3

[RudolfGerber09]

@maxime-esa can you also provide an Windows binary?

[maxime-esa]

Done, I've uploaded it in the same place.

[RudolfGerber09]

Maxime, I downloaded the windows binary on friday last week. When I run the new version I realize following problems:
1. --version parameter reports 4.3.1.1.
2. I can't find the new switch --slim when I call help

Can you please help me with this 2 topics?

[maxime-esa]

I re-generated the binary, can you try again? https://github.com/ttsiodras/asn1scc/releases/download/4.3.1.3/asn1scc-win64-4.3.1.3.zip

[RudolfGerber09]

OK, both is correct now.
Thanks for the quick fix.