Bootstrapping a null procedure. Seriously?!

Bootstrapping a null procedure. Seriously?!

[Diogenes]

I've been doing some binder experiments with this little gem....

procedure nullmain is

begin

  null;

end nullmain;


Been doing it to see just how many packages from the runtime have to be linked in order for the the thing to DO NOTHING!

40 packages are pulled in.

By most measures of good software design, this is WRONG.

So here's the question...

Do I need to have different a-finali.ads/.adb packages and the corresponding crt1.o implementations for every possible variation on the runtime I could ever want? I mean, seriously, it's pulling in system.string_opts; does anyone see strings in the above code?

Of course I realize this is partly due to package dependency issues, however I SHOULD be able to write my own a-finali.ads that does nothing but make a _start symbol for the system linker, right?

Tips?

Re: Bootstrapping a null procedure. Seriously?!

[Georg Bauhaus]

On 11.03.13 11:37, Diogenes wrote:
> I've been doing some binder experiments with this little gem....
>
> procedure nullmain is

> Been doing it to see just how many packages from the runtime have to be linked in order for the the thing to DO NOTHING!

> Tips?

Compilers may let you choose run-time systems.
With GNAT, look up --RTS, pragma No_Run_Time,
Configurable Runtime, and related documentation.

A program nullmain is quite rare; I'd therefore not expect
special circuitry to be built into the compiler for just
this null program. Rather, a run-time system of an
Ada compiler supports full Ada programs by default,
including tasking and exceptions. See below, and above.

The program nullmain doesn't actually do nothing.
For a start, you can run the resulting executable,
This creates a state change in your computer.
OK, this may be nitpicking.

Nullmain is, however, going to run as required by Ada,
and as a rule of thumb, every statement can raise
storage error, which might well be what an author
of a null program wishes to happen, for testing, say.

Nullmain will be running as part of the environment task,
as expected.

Nullmain may also be just a partition of a program, for some
reason however likely or unlikely. Etc.

That's the default. Choose a smaller run-time and
add configuration pragmas as needed, if you need to.

Re: Bootstrapping a null procedure. Seriously?!

[Diogenes]

Actually I just need to figure out how to write a crt0.o file just for bootstrapping the Runtime.

That shouldn't be too hard. Really, all the machine needs is a _start point. I can gradually add parts of the runtime/kernel from there.

I'd like to build a runtime/profile that's slightly less rigorous than the Ravenscar profile. It would allow Generics and allow Dynamic Memory allocation only through the use of explicitly declared Storage Pools. Suspect I'll have to do some in depth compiler hacking for that though.

Re: Bootstrapping a null procedure. Seriously?!

[Robert A Duff]

Diogenes <phathax0r@gmail.com> writes:

> I'd like to build a runtime/profile that's slightly less rigorous than
> the Ravenscar profile. It would allow Generics and allow Dynamic
> Memory allocation only through the use of explicitly declared Storage
> Pools. Suspect I'll have to do some in depth compiler hacking for that
> though.

Take a look at Default_Storage_Pool.

- Bob

Re: Bootstrapping a null procedure. Seriously?!

[Brian Drummond]

On Mon, 11 Mar 2013 14:14:37 -0700, Diogenes wrote:

> Actually I just need to figure out how to write a crt0.o file just for
> bootstrapping the Runtime.
> 
> That shouldn't be too hard. Really, all the machine needs is a _start
> point. I can gradually add parts of the runtime/kernel from there.
> 
> I'd like to build a runtime/profile that's slightly less rigorous than
> the Ravenscar profile. It would allow Generics and allow Dynamic Memory
> allocation only through the use of explicitly declared Storage Pools.
> Suspect I'll have to do some in depth compiler hacking for that though.

This tutorial on a minimal RTS may be useful (thanks to Luke Guest).

http://wiki.osdev.org/Ada_Bare_bones

Or see the RTS component of the AVR-Ada project on Sourceforge for 
another minimal RTS.

- Brian

Re: Bootstrapping a null procedure. Seriously?!

[Diogenes]

On Tuesday, March 12, 2013 8:09:08 AM UTC-4, Brian Drummond wrote:
> 
> 
> This tutorial on a minimal RTS may be useful (thanks to Luke Guest).
> 
> 
> 
> http://wiki.osdev.org/Ada_Bare_bones
> 
> 
> 
> Or see the RTS component of the AVR-Ada project on Sourceforge for 
> 
> another minimal RTS.
> 
> 
> 
> - Brian

Yeah...these projects are what got me interested in doing this.

Is it actually possible to compile the nullmain.adb procedure against these runtimes and have it actually load on their respective platforms?

Re: Bootstrapping a null procedure. Seriously?!

[Brian Drummond]

On Tue, 12 Mar 2013 07:04:12 -0700, Diogenes wrote:

> On Tuesday, March 12, 2013 8:09:08 AM UTC-4, Brian Drummond wrote:

>> http://wiki.osdev.org/Ada_Bare_bones
>> Or see the RTS component of the AVR-Ada project on Sourceforge for
>> another minimal RTS.

> Yeah...these projects are what got me interested in doing this.
> 
> Is it actually possible to compile the nullmain.adb procedure against
> these runtimes and have it actually load on their respective platforms?

I have done so for the AVR-Ada runtime (and an experimental port to the 
Texas MSP430). The Ada main subprogram compiles down to "ret" . For the 
MSP430 version, the whole executable is about 200 bytes (mostly crt0.s, 
but including 32 bytes of interrupt vectors. The AVR-Ada project is 
further along : a complete LED flasher is about 65 bytes, of which the RTS 
is probably 50 bytes.

- Brian

Re: Bootstrapping a null procedure. Seriously?!

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:513dbf68$0$6580$9b4e6d93@newsspool3.arcor-online.net...
> On 11.03.13 11:37, Diogenes wrote:
>> I've been doing some binder experiments with this little gem....
>>
>> procedure nullmain is
>
>> Been doing it to see just how many packages from the runtime have to be 
>> linked in order for the the thing to DO NOTHING!
>
>> Tips?
...
> A program nullmain is quite rare; I'd therefore not expect
> special circuitry to be built into the compiler for just
> this null program. Rather, a run-time system of an
> Ada compiler supports full Ada programs by default,
> including tasking and exceptions. See below, and above.

Right. It's hardly ever worth it to worry about such cases, because real 
programs do some sort of I/O, raise exceptions, and so on. Janus/Ada does 
have code to eliminate the tasking support in the case that it isn't used 
anywhere (we have a dummy task supervisor which is much smaller than the 
real one, so that generic instantiations and limited types will not need 
special code), but that's the only case that ever seemed worthwhile (and 
that's not as clear these days as it was back in the days of MS-DOS).

                                     Randy.

Re: Bootstrapping a null procedure. Seriously?!

[anon]

To compile a barebone Ada program you must not use "gnatmake" 
or "gnat make" because it auto execute the Ada binder "gnatbind" 
and the "gnat linker". Gnat's binder and linker can not be used 
because they creates an os bound program. And they also adds a 
number of simple routines that may not be required for your 
program.

Any and all subunits and libraries that requires elaboration must 
be done manually first, within the main program. Normally this job 
is handled by the Gnat binder. The elaboration code can be in cased 
within a procedure or function that is called by the main program.

Also, you can not use the standard "raise" statement or the 
standard exception handlers. For exceptions to work, Gnat
compiler requires a number of System packages be load as well 
as "Ada.Exceptions". 


# --
# --  Makefile
# --
gnat compile testnulmain.adb
#
#  use -nostdinclib to remove most of gcc standard libraries
#      but os startup code is included from "libc".
#  additional libraries files, if included must be added to 
#  the command line.
#  
#  To reduce code to the basic user created only code use the
#   -T <file> command. The file defines ".text", ".data", 
#  ".rodata", and ".bss" setions and then discard all other 
#  sections.
#
#  Note: use -o testnulmain.exe for all microsoft based os(s)
#        gcc only support ".com" files with the -T <file> option
#
gcc -nostdinclib -o testnulmain testnulmain.o


--
--  testnulmain.ads
--
procedure testnulmain ;
  --
  --  Required by linker
  --
  pragma Export ( Ada, testnulmain, "main" ) ;


--
--  testnulmain.adb
--
--    Can include "Stand-Alone" Ada packages, like Ada.Characters,
--    Ada.Interfaces, or System. Actually any Ada library that 
--    does not require direct or indirect OS linking can be used.
--
with System ;
procedure TestNulMain is

  --
  --  In this example System.o is not needed to link file
  --
  TestVar : System.Address := System.Null_Address ;

begin

  --  preform elaboration here first

  null ;
end TestNulMain ;


In <19d330ec-9b61-414e-abc3-e25a8c786b81@googlegroups.com>, Diogenes <phathax0r@gmail.com> writes:
>I've been doing some binder experiments with this little gem....
>
>procedure nullmain is
>
>begin
>
>  null;
>
>end nullmain;
>
>
>Been doing it to see just how many packages from the runtime have to be lin=
>ked in order for the the thing to DO NOTHING!
>
>40 packages are pulled in.
>
>By most measures of good software design, this is WRONG.
>
>So here's the question...
>
>Do I need to have different a-finali.ads/.adb packages and the correspondin=
>g crt1.o implementations for every possible variation on the runtime I coul=
>d ever want? I mean, seriously, it's pulling in system.string_opts; does an=
>yone see strings in the above code?
>
>Of course I realize this is partly due to package dependency issues, howeve=
>r I SHOULD be able to write my own a-finali.ads that does nothing but make =
>a _start symbol for the system linker, right?
>
>Tips?
>

Re: Bootstrapping a null procedure. Seriously?!

[Oliver Kleinke]

Am Mon, 11 Mar 2013 03:37:59 -0700 (PDT)
schrieb Diogenes <phathax0r@gmail.com>:

> I've been doing some binder experiments with this little gem....
> 
> procedure nullmain is
> 
> begin
> 
>   null;
> 
> end nullmain;
> 
> 
> Been doing it to see just how many packages from the runtime have to
> be linked in order for the the thing to DO NOTHING!
> 
> 40 packages are pulled in.
> 
> By most measures of good software design, this is WRONG.
> 
> So here's the question...
> 
> Do I need to have different a-finali.ads/.adb packages and the
> corresponding crt1.o implementations for every possible variation on
> the runtime I could ever want? I mean, seriously, it's pulling in
> system.string_opts; does anyone see strings in the above code?
> 
> Of course I realize this is partly due to package dependency issues,
> however I SHOULD be able to write my own a-finali.ads that does
> nothing but make a _start symbol for the system linker, right?
> 
> Tips?
> 

Have you tried to let the compiler "garbage collect"[1] the unused code?

--
[1]
http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Reducing-Size-of-Executables-with-unused-subprogram_002fdata-elimination.html