Configuring for bare hw ia32 PC's

Joel Sherrill joel.sherrill@oarcorp.com
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:
> http://www.archeia.com/an-ada95-hello-world-style-kernel.html
>
>   
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.

> Thanks,
> Luke.
>
>
>   


-- 
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 mailing list