Configuring for bare hw ia32 PC's
Thu May 15 10:50:00 GMT 2008
Luke A. Guest wrote:
> On Tue, 2008-05-13 at 08:49 -0500, Joel Sherrill wrote:
>>> Er, no. This is the way that Ada works. There are parts of the language
>>> which when compiled, the compiler adds in extra bits of support.
>> Right. It assumes a lot of things exist. For the tasking to
>> work, you need a lot. RTEMS uses the POSIX threads port
>> which by default assumes pthreads, mutexes, condition
>> variables and keys. The GNAT run-time also includes
> No need to have this. I'm going to be implementing my own tasking model,
> so that when I come to port GNAT to work on top of my kernel, then I'll
> have full Ada :D
Good luck. Your tasking implementation has to match their
expectations on semantics or you can get some weird issues.
I remember them at one point depending on a particular
way threads got queued in a particular situation where I
didn't think POSIX was that specific. And that's a defined
standard -- not just a random API.
I'm not saying it can't be done -- just the the Ada run-time
has its own assumptions and you will have to be careful.
>> a socket binding. The Ada run-time has a lot of nice
>> formatted IO support which I have no idea how it is
>> implemented in GNAT.
> The IO is all based on POSIX calls, so open, close, read, write, etc.
We have all of that and newlib so I never bothered to care what
they call. :-D
>>>> Back up a second. You are, in effect, compiling Ada code to run on a
>>>> bare board. The "hosted" specification of the standard C library assumes
>>>> that you are running on top of an operating system. The "freestanding"
>>>> version does not.
>>>> It is okay if the Ada compiler emits things that rely on the
>>>> freestanding version of libc. Pragmatically, it is also okay if it
>>> Do you mean, "is it?" I would say, no that's fine. I want a basic
>>> runtime, just not the extra bits. Unfortunately, the way the GNAT source
>>> is built, there doesn't seem (I could be wrong) to be a way to say, I
>>> only want this and this and this, not that.
>> They used to and may still have a bare non-tasking configuration.
> There are options that you can set inside system.ads, so I'd have to
> create a runtime directory in my build tree and copy over the parts I
> need. I would then modify the system.ads file to say what I want to
> include in the runtime.
You can also put your own system-XXX.ads in the source tree
if you like.
> I did actually do this already:
Nice so far.
FWIW RTEMS is in C. :-D
Out of curiousity, how big it your hello world?
>>> The initialisation code will generate a call to memcpy. This is
>>> something I will most probably want to include in *my runtime*.
>> And it is not uncommon to find it automatically generating
>> calls to lock a run-time structure either.
> Ah, but I won't be using tasking so it shouldn't generate those either,
> this is a flag in system.ads as well, IIRC.
There are lots of flags in there. :-D
>>> Also, to actually get the gnat tools (e.g. gnatmake, gnatclean, etc) you
>>> have to build the runtime. Also, I suspect that to get ASIS (which may
>>> be necessary) you also need the runtime and the tools. :(
>> You can cross compile. That's what we do.
> Yes, but don't you use gnatmake for your build? This requires a full
> toolset which you won't get until you've ported GNAT over to your OS for
> that platform. The way I did it was to use the cross tool i386-elf-gcc
> and ï»¿i386-elf-gnatbind programs, I then link by hand.
Yes we use CPU-rtems-gnatmake for the build. Just takes
care to pass in the right -cargs, -largs, etc.
I don't see why you can't use gnatmake and gnatbind. Just
a matter of getting the arguments right.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the Newlib