Change static const to static constexpr in addrmap.h.j2

[emrebayrm]

if it is compiled with no optimization, since object is not initialized, no memory created, this will not be compiled because of linker error.

hal.somefield.set(hal::xenum::SOME_CONST); // this won't work.
auto val = hal::xenum::SOME_CONST;
hal.somefield.set(val); // this still work tho

however since it is pretty much like a constexpr value, if the code compiled with optimization flags ON, compiler can detect and replace with a value so no job for linker, all is good.

Since the intention is to use as constexpr, lets make the type as intended.

[emrebayrm]

Hey @Risto97 I believe you are working with on risc-v compilers, have you seen this issue there?

[Risto97]

Hello @emrebayrm ,

Sorry I had not have time to recreate it.
What would help me a lot if you could give me a minimal systemrdl example, along with an example main.cpp, so I could recreate.

Currently there is a #12 branch for testing, but I have no time to improve it and merge.

[emrebayrm]

Simply it exist with the example as well, I've just pushed simple main and cmake to compile if you compile with O0 (which is generally CMAKE_BUILD_TTYPE=Debug)

Wait, this was not only for Const but also others, let me try to fix that.

[Risto97]

Not exactly what I meant,
I pushed a commit that adds the example I presumed you are referring to.
As in order to generate the halcpp::Const member we need to use enum and encode.

I will need still more time to analyze this, sorry I dont have much time to spend on this project.
I hope to do a rewrite of the Python codebase at some point, as currently it is not in the greatest state.

[emrebayrm]

Yes sorry, I was aware but responded in a rush maybe, so couldn't answer clearly. My purpose was to also show, the issue does not exist only in enums but also in current example, as well.

Because it is about static variables in class, when they are not compiled with optimization. Static variables simply only defined not actually initialized, only when they are defined like static inline xxxx{}; then, they are initialized, will have a space.

if you compile the same application with O0, you will see that compiler will complain about linkage error. xxx is not found etc. however if you compile with optimization O1 then compiler will resolve addresses automatically so that static variables doesn't need to be initalized because actually, all abstraction is to hide a address computation and compiler will do that and resolve it. I should have update the description, sorry.

Yes, maybe true that it is not greatest state, but even current state it is very useful and insightful, thank you for all the efforts, deserves applause 👏.
Thank you taking time on this matter. I am planning to do more stuff like extra namespacing for regfile blocks, I will keep developing them in my fork, then I can open PR here, you can review wheneve you are have time.

Thanks.

[Risto97]

Ah yes, you are right about that, this is definitely an issue.
Making it static inline does fix it.

If you need this urgently you can maybe have this on a fork for now.
I want to improve the testing of this tool, and also to modernize the repository (use pyproject.toml, static type checking etc...) before doing major updates.

I made a lot of effort initially so that these abstraction are zero cost, these object should not take any memory, and also it should compile to a minimal assembly.
Unfortunately, I never invested effort in a proper CI, and testing, which is a big problem now.
What I would like to have is a pipeline that checks if all these test cases compile and run, but also I want to monitor if it affects the binary size when compiled. It should compile also for few architectures and compilers (Clang, GCC) (ARM, RiscV, X86).
This way we can make sure that none of the changes we do are affecting the abstraction cost.

If you feel like you would find this interesting to work on, I will be very happy to accept help working on this.

[emrebayrm]

Yes at the moment I have more changes even in my fork :D like I implemented namespace block from regfile blocks as well :D.

That would be really great, those are all almost must for a properly maintained framework plugin and besides gives more confidence while doing changes. but in my opinion instead of doing all in big chunk, shall we do piece by piece? if we split the work small pieces, I can help. like first put differen compilation, lets make ci ready for testing etc. then implements tests piece by piece?

[Risto97]

Yes, I agree we should tackle it bit by bit.
As a first step I made a branch #24 , I reconstruct the repository using a cookiecutter-uv template I typically use for new project.
This sets some static code checking. Feel free to take a look and give feedback, or push commits.

There are issues that need to be resolved before we can merge this, mostly static type check issues.