Re: Unifont static compiled and stack size...

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2023-08-13 19:16, Micah Waddoups wrote:
> I tried to compile the Unifont hex file, converted with a script into
> variable Ada code, but it went on forever, gradually blowing up my
> memory.  I used an .ads file and aimed for a static build, but I
> suspect I would have hit the stack size limit for executables if I
> succeeded
> 
> My request for insight is: (A) How do you recommend I compile the
> Unifont into a form that is usable within my Ada program.

Could you show a little of the script-generated Ada code, just for us to 
understand the approach you have taken to represent the Unifont file?

While waiting for that, it may help the compiler if you disable the more 
advanced compiler optimizations, because some of them are super-linear 
in complexity and probably (but depending on the exact form of the Ada 
code) do not help for this case, anyway.


> (I am thinking compiling C and importing, since C is so basic it
> might just work, but even better would be Assembly and I don't know
> how to import a large data variable compiled in Assembly or if I can
> even compile that much data using Assembly...  It should work, but
> the compiler might complain and I still have to figure out the
> importing part.)

I'm not familiar with the structure of the Unifont file, but if it is 
something like a table with rows and columns, it should be rather easy 
to translate it into a list of assembly-language constant-data definitions.

Assemblers are typically linear in complexity and should be able to 
handle large data definitions, assuming there is not a myriad of 
assembler labels that make references between different parts of the 
data structure.

Exporting a data object from assembly to Ada is simple and does not 
depend on the size of the object (but I admit I don't know how this is 
done for dynamically linked libraries). The only part that needs thought 
is how to define the Ada type of the object, but if the Unifont file is 
a row-column table, in other words a list of "row" records, that should 
be straight-forward too.

So I think the assembly-language solution is highly likely to work; its 
drawback, of course, is non-portability. But the constant-data 
definitions of most assembly languages are very similar to each other, 
so the assembler-generating script should be easy to port to different 
assembly languages.