From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Unifont static compiled and stack size... Date: Mon, 14 Aug 2023 11:07:14 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net YrbEjvEMdV3CnWJEav8xGgc8u2sJimzPYVzUP6NcdmRgRcqypb Cancel-Lock: sha1:SPVdR2OlkMN2L/liC9Axp7Md8yU= sha256:JS7ZcUS1SlbPiCy2+ZqJ3XCU2emEet8ON72dw+RRb2k= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: en-US In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:65514 List-Id: 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.