User talk:Ajxs/Ada Runtime Library

The GPRBuild package is not available through the FSF, it is specific to GNAT Pro or GNAT GPL via AdaCore's website.

It looks like GPRBuild is distributed by the FSF. I could be wrong about this since I don't have it infront of me, but I came to that conclusion from the fact that the version available from the Ubuntu repos lists the FSF in the '--version' text. It also looks like it's available from the FSF here: https://directory.fsf.org/wiki/Gprbuild --Ajxs 03:22, 24 September 2019 (CDT)

That page shows 2 links where to get them, 1 to AdaCore and 1 to debian, who get it from AdaCore.--Lucretia 03:31, 24 September 2019 (CDT)

You're right about it being an AdaCore product. I'm not sure of what difference where you get it has on licensing, if any. I assumed that the FSF had built it from source and relicensed it. I'll also pay more attention to my labeling of AdaCore GNAT PRO vs GNAT GPL too. --Ajxs 03:56, 24 September 2019 (CDT)

GPRBuild is only available from AdaCore and it is GPLv3 like all their stuff.--Lucretia 06:14, 24 September 2019 (CDT)

I would link to [1] as well as to the libre site, it is currently difficult to know which commits work from GH for specific versions of GCC.--Lucretia 03:35, 24 September 2019 (CDT)

I would change the following:

The GNAT compiler offers a facility for configuring the runtime-library used during the compilation process. This is done by either using the --RTS=example command-line switch, or by using the for Runtime ("Ada") use "example"; directive in the project’s configuration file.

to:

The GNAT compiler offers a facility for specifying a different runtime-library used during the compilation process. This is done by either using the --RTS=example command-line switch, or by using the

for Runtime ("Ada") use "example";

directive in the project’s configuration file. --Lucretia 03:40, 24 September 2019 (CDT)

---

I think "the approach recommended by AdaCore is to create and link against an empty run-time library." needs more elaboratio; 1) where do they say this? 2) What constitutes an empty library?

Forgive me, I was misquoting AdaCore from this page. They did not use the term "empty run-time", that was my mistake. I'll amend the article to correct this. --Ajxs 22:38, 5 October 2019 (CDT)

This doesn't read well and is confusing:

"As noted in the source code comments above, the run-time sources are used as a dummy run-time to build the run-time library itself. One method to implement this is to include a pre-requisite step in your makefile to copy the sources to the final build destination adainclude directory, then to specify this build directory as the run-time for the project."

1) It's not really a dummy runtime. 2) The Copying of the runtime sources is really annoying and confusing, you can make symbolic links to them if you must have them in a separate source dir, GNAT usually just dumps specs and bodies in adainclude. But why not just set the Source_Dirs directive in the GPR to runtime/sources?

--Lucretia 03:43, 5 October 2019 (CDT)

My reason for not taking the same approach that you did in regards to creating the RTS adainclude directory is that I like to conceptualise the resulting 'build' directory as being a portable, final built artifact of the build process. This is just a matter of opinion I guess, one that I have ported over to Ada from my approach in C. I agree that copying things over is a bit clumsy, I just went with the approach that requires the least effort to understand at a glance.

I'll amend the wording of "dummy run-time" as well. --Ajxs 22:38, 5 October 2019 (CDT)

---

I think to make this a full discussion/explanation of the RTS, I think this should be expanded further. I implemented a small secondary stack in bare bones on github - [2], this should be added to this discussion as an extension to ZFP but allows the developer to be more flexible with the kind of Ada they write, being able to return indefinite types is really handy. You'l also see from the bare bones source that the secondary stack enables hte use of 'Image attributes as well.

Also, I have memcpy [3] implemented so you can assign objects to each other, this is also something which should go into the RTS and should be written about here, I don't have it mentioned in the main article, because I implemented that later.

You're absolutely right. A secondary stack is a very, very valuable addition. A memcpy implementation is a great point too. --Ajxs 22:38, 5 October 2019 (CDT)

The topic is extremely broad, so you'll have to forgive me falling behind in a few areas. I've tried to tackle the simpler aspects first. To avoid getting myself stuck into going overboard and going into too much detail I'd tried to keep the article a good balance of being practical to the topic of osdev, as well as being theoretically correct and providing a good introduction to the topic in an academically correct way. There's so much more that can be written on the runtime as a whole. None of this is to say that the article is anywhere near fully complete though. There's lots more to add with time, and I really appreciate your help! :) If you can think of other good topics to add feel free to list them and I'll be happy to do some more research. As I think I mention somewhere else, if you'd like me to publish it so you can edit and get the full credit I'm happy to go that route. --Ajxs 22:38, 5 October 2019 (CDT)

I think that this should also go into more detail on the gnat.adc file, like I do in the main bare bones article here.

Good idea. Would you like me to do this? If I publish the page in the mainstream you would be able to do the editing yourself and receive the proper credit if you wanted. Otherwise I'm happy to write it up myself. --Ajxs 22:38, 5 October 2019 (CDT)

I would like to clean up my bare bones article and source code, so that:

1) The source is Ada 2012. 2) The main article references this one, so this needs to really implement anything I have in the main article relating to the RTS so I can strip it out. 3) Write a further article covering the PC's board support package, which I've already started in bare bones, and you've already started with the port i/o package.

As part of the BSP article, I would like help to get multiboot.ad[sb] updated, I never did work out how to get the parameters from the command line, which I think is the new way of getting the boot parameters from grub, having this would make that package about as perfect as you can get. Multiboot should stand on it's own and not be under a PC root package, remember the multiboot standard is portable to other platforms.

I've made a very simple initial implementation of this in my 'cxos' kernel example. You can see how I initialise the runtime and propagate the GRUB magic number and info structure to my multiboot init function here in this file x86-multiboot-start.S. This is part of the base system initialisation process, which takes place within the RTS, as I talk about in the article here. You can see the structures used and associated functionality in the x86-multiboot.ads file and associated package body.

Careful with these links, they might change very soon. But they should be good for a few days.

If you want me to do any of the editing here I'm happy to.

What you said about Multiboot not being PC specific is very valid. It's a great suggestion that I'll take that on board in my own work! --Ajxs 22:38, 5 October 2019 (CDT)

But the Console package can be a child of the PC package.

I'm happy to start cleaning up the bare bones source into separate repos to enable this split.

Awesome. Feel free to reach out if you need any help from me. --Ajxs 22:38, 5 October 2019 (CDT)

--Lucretia 05:00, 5 October 2019 (CDT)