Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #112431 > unrolled thread

Freestanding Environment

Back to article view | Back to comp.lang.c

Contents

  Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-17 19:58 -0700
    Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 00:15 -0500
      Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-17 23:51 -0700
        Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 02:31 -0500
          Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-18 14:08 -0700
            Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 21:19 -0500
              Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-18 19:49 -0700
                Re: Freestanding Environment Keith Thompson <kst-u@mib.org> - 2017-06-19 09:10 -0700
                  Re: Freestanding Environment supercat@casperkitty.com - 2017-06-19 09:42 -0700
                    Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 16:51 +0000
                      Re: Freestanding Environment supercat@casperkitty.com - 2017-06-19 12:26 -0700
                        Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 19:37 +0000
                          Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-19 17:51 -0700
                    Re: Freestanding Environment Keith Thompson <kst-u@mib.org> - 2017-06-19 12:39 -0700
                  Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-19 17:45 -0700
                    Re: Freestanding Environment Keith Thompson <kst-u@mib.org> - 2017-06-20 08:32 -0700
                      Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-20 12:29 -0700
                        Re: Freestanding Environment raltbos@xs4all.nl (Richard Bos) - 2017-06-26 15:58 +0000
                          Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-26 09:25 -0700
                            Re: Freestanding Environment raltbos@xs4all.nl (Richard Bos) - 2017-06-26 20:17 +0000
                              Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-26 14:03 -0700
                              Re: Freestanding Environment joel.rees@gmail.com - 2017-06-27 18:04 -0700
                                Re: Freestanding Environment James Kuyper <jameskuyper@verizon.net> - 2017-06-27 21:47 -0400
                                  Re: Freestanding Environment bartc <bc@freeuk.com> - 2017-06-28 11:45 +0100
                                  Re: Freestanding Environment Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-28 03:55 -0700
                                    Re: Freestanding Environment Richard Heathfield <rjh@cpax.org.uk> - 2017-06-28 12:32 +0100
                                      Re: Freestanding Environment Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-28 05:45 -0700
                                        Re: Freestanding Environment James Harris <james.harris.1@gmail.com> - 2017-06-28 21:42 +0100
                                          Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-29 13:27 +0000
                                          Re: Freestanding Environment Mark Storkamp <mstorkamp@yahoo.com> - 2017-06-29 08:44 -0500
                                            Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-29 13:54 +0000
                                              Re: Freestanding Environment Mark Storkamp <mstorkamp@yahoo.com> - 2017-06-29 11:11 -0500
                                                Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-29 16:45 +0000
                                                Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-30 00:34 -0500
                                            Re: Freestanding Environment Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-29 16:07 -0400
                                        Re: Freestanding Environment James Kuyper <jameskuyper@verizon.net> - 2017-06-28 16:53 -0400
                                          Re: Freestanding Environment James Harris <james.harris.1@gmail.com> - 2017-06-29 10:58 +0100
                                            Re: Freestanding Environment "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-29 12:19 -0400
                                              Re: Freestanding Environment James Harris <james.harris.1@gmail.com> - 2017-06-30 08:16 +0100
                                      Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-28 11:28 -0500
                                      Re: Freestanding Environment James Kuyper <jameskuyper@verizon.net> - 2017-06-28 14:38 -0400
                                        Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-28 18:48 +0000
                            Re: Freestanding Environment Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 16:42 -0400
                              Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-26 14:05 -0700
                                Re: Freestanding Environment Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 17:31 -0400
                                Re: Freestanding Environment joel.rees@gmail.com - 2017-06-27 02:36 -0700
                                  Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-27 12:43 +0000
                                    Re: Freestanding Environment Robert Wessel <robertwessel2@yahoo.com> - 2017-06-27 09:50 -0500
                  Re: Freestanding Environment joel.rees@gmail.com - 2017-06-27 18:11 -0700
              Re: Freestanding Environment "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-20 20:22 +0200
                Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-20 12:33 -0700
            Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 13:11 +0000
            Re: Freestanding Environment Mark Storkamp <mstorkamp@yahoo.com> - 2017-06-19 08:53 -0500
        Re: Freestanding Environment scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 13:08 +0000
          Re: Freestanding Environment David Kleinecke <dkleinecke@gmail.com> - 2017-06-19 17:40 -0700
      Re: Freestanding Environment Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:16 -0700
    Re: Freestanding Environment supercat@casperkitty.com - 2017-06-19 07:59 -0700

Page 1 of 3  [1] 2 3  Next page →

#112431 — Freestanding Environment

In section 5.1.2.1 of the C90 standard it says:
   In a freestanding environment (in which C program 
   execution may take place without any benefit of an
   operating system), the name and type of the function
   called at program startup are implementation-defined.
   There are otherwise no reserved external identifiers.
   Any library facilities to a free-standing program
   are implementation-defined.

It is actually possible to create a non-trivial program
of this sort without any library support.

Non-trivial to exclude

   int main (void) {
      return 0;}

and the like. I have toyed with memory-addressed i/o but
I think the i/o addresses must be additional reserved 
external identifiers. 

[toc] | [next] | [standalone]

#112441

On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>In section 5.1.2.1 of the C90 standard it says:
>   In a freestanding environment (in which C program 
>   execution may take place without any benefit of an
>   operating system), the name and type of the function
>   called at program startup are implementation-defined.
>   There are otherwise no reserved external identifiers.
>   Any library facilities to a free-standing program
>   are implementation-defined.
>
>It is actually possible to create a non-trivial program
>of this sort without any library support.
>
>Non-trivial to exclude
>
>   int main (void) {
>      return 0;}
>
>and the like. I have toyed with memory-addressed i/o but
>I think the i/o addresses must be additional reserved 
>external identifiers. 


Why would you think memory mapped I/O addresses need to be reserved
identifiers?  If the serial port is at 0xf120, and the write register
is at +1, you might well send a character by executing:

  *(((unsigned char *)0xf120)+1) = 'A';

(Tossing a "volatile" in there might be a good idea).

In any event, just because the standard reserves no external
identifiers in the case of a freestanding implementation, doesn't mean
there aren't some/many used by the implementation.

[toc] | [prev] | [next] | [standalone]

#112444

On Saturday, June 17, 2017 at 10:16:07 PM UTC-7, robert...@yahoo.com wrote:
> On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >In section 5.1.2.1 of the C90 standard it says:
> >   In a freestanding environment (in which C program 
> >   execution may take place without any benefit of an
> >   operating system), the name and type of the function
> >   called at program startup are implementation-defined.
> >   There are otherwise no reserved external identifiers.
> >   Any library facilities to a free-standing program
> >   are implementation-defined.
> >
> >It is actually possible to create a non-trivial program
> >of this sort without any library support.
> >
> >Non-trivial to exclude
> >
> >   int main (void) {
> >      return 0;}
> >
> >and the like. I have toyed with memory-addressed i/o but
> >I think the i/o addresses must be additional reserved 
> >external identifiers. 
> 
> 
> Why would you think memory mapped I/O addresses need to be reserved
> identifiers?  If the serial port is at 0xf120, and the write register
> is at +1, you might well send a character by executing:
> 
>   *(((unsigned char *)0xf120)+1) = 'A';
> 
> (Tossing a "volatile" in there might be a good idea).
> 
> In any event, just because the standard reserves no external
> identifiers in the case of a freestanding implementation, doesn't mean
> there aren't some/many used by the implementation.

I am not making myself perfectly clear. This is in part because
the standard is not perfectly clear. So I may be using the wrong
names for things. 

As for your example IMO the 0xf120 is a piece of information
that the hosting environment must supply and therefore must
be implemented as the value of a reserved external identifier
(if that phrase means information supplied to the program by  
its host).

[toc] | [prev] | [next] | [standalone]

#112445

On Sat, 17 Jun 2017 23:51:05 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Saturday, June 17, 2017 at 10:16:07 PM UTC-7, robert...@yahoo.com wrote:
>> On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
>> <dkleinecke@gmail.com> wrote:
>> 
>> >In section 5.1.2.1 of the C90 standard it says:
>> >   In a freestanding environment (in which C program 
>> >   execution may take place without any benefit of an
>> >   operating system), the name and type of the function
>> >   called at program startup are implementation-defined.
>> >   There are otherwise no reserved external identifiers.
>> >   Any library facilities to a free-standing program
>> >   are implementation-defined.
>> >
>> >It is actually possible to create a non-trivial program
>> >of this sort without any library support.
>> >
>> >Non-trivial to exclude
>> >
>> >   int main (void) {
>> >      return 0;}
>> >
>> >and the like. I have toyed with memory-addressed i/o but
>> >I think the i/o addresses must be additional reserved 
>> >external identifiers. 
>> 
>> 
>> Why would you think memory mapped I/O addresses need to be reserved
>> identifiers?  If the serial port is at 0xf120, and the write register
>> is at +1, you might well send a character by executing:
>> 
>>   *(((unsigned char *)0xf120)+1) = 'A';
>> 
>> (Tossing a "volatile" in there might be a good idea).
>> 
>> In any event, just because the standard reserves no external
>> identifiers in the case of a freestanding implementation, doesn't mean
>> there aren't some/many used by the implementation.
>
>I am not making myself perfectly clear. This is in part because
>the standard is not perfectly clear. So I may be using the wrong
>names for things. 
>
>As for your example IMO the 0xf120 is a piece of information
>that the hosting environment must supply and therefore must
>be implemented as the value of a reserved external identifier
>(if that phrase means information supplied to the program by  
>its host).


I think that usually a reserved external identifier would be something
like errno or strcmp.  See section 7.1.3 (that's the spot in the C99
and C11 standards).

But for a freestanding implementation, the standard basically
specifies nothing about how the program might interact with its
environment.

[toc] | [prev] | [next] | [standalone]

#112501

On Sunday, June 18, 2017 at 12:31:49 AM UTC-7, robert...@yahoo.com wrote:
> On Sat, 17 Jun 2017 23:51:05 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >On Saturday, June 17, 2017 at 10:16:07 PM UTC-7, robert...@yahoo.com wrote:
> >> On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
> >> <dkleinecke@gmail.com> wrote:
> >> 
> >> >In section 5.1.2.1 of the C90 standard it says:
> >> >   In a freestanding environment (in which C program 
> >> >   execution may take place without any benefit of an
> >> >   operating system), the name and type of the function
> >> >   called at program startup are implementation-defined.
> >> >   There are otherwise no reserved external identifiers.
> >> >   Any library facilities to a free-standing program
> >> >   are implementation-defined.
> >> >
> >> >It is actually possible to create a non-trivial program
> >> >of this sort without any library support.
> >> >
> >> >Non-trivial to exclude
> >> >
> >> >   int main (void) {
> >> >      return 0;}
> >> >
> >> >and the like. I have toyed with memory-addressed i/o but
> >> >I think the i/o addresses must be additional reserved 
> >> >external identifiers. 
> >> 
> >> 
> >> Why would you think memory mapped I/O addresses need to be reserved
> >> identifiers?  If the serial port is at 0xf120, and the write register
> >> is at +1, you might well send a character by executing:
> >> 
> >>   *(((unsigned char *)0xf120)+1) = 'A';
> >> 
> >> (Tossing a "volatile" in there might be a good idea).
> >> 
> >> In any event, just because the standard reserves no external
> >> identifiers in the case of a freestanding implementation, doesn't mean
> >> there aren't some/many used by the implementation.
> >
> >I am not making myself perfectly clear. This is in part because
> >the standard is not perfectly clear. So I may be using the wrong
> >names for things. 
> >
> >As for your example IMO the 0xf120 is a piece of information
> >that the hosting environment must supply and therefore must
> >be implemented as the value of a reserved external identifier
> >(if that phrase means information supplied to the program by  
> >its host).
> 
> 
> I think that usually a reserved external identifier would be something
> like errno or strcmp.  See section 7.1.3 (that's the spot in the C99
> and C11 standards).
> 
> But for a freestanding implementation, the standard basically
> specifies nothing about how the program might interact with its
> environment.

I think the standard requires the environment to specify
which function in a fully-linked freestanding bundle of
functions is where execution is to be started. My question
was Are there any non-trivial programs that do not demand
further interaction with the environment?

The concept I am groping for is exactly what the hosting
environment of a free-standing C program looks like.

[toc] | [prev] | [next] | [standalone]

#112525

On Sun, 18 Jun 2017 14:08:52 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Sunday, June 18, 2017 at 12:31:49 AM UTC-7, robert...@yahoo.com wrote:
>> On Sat, 17 Jun 2017 23:51:05 -0700 (PDT), David Kleinecke
>> <dkleinecke@gmail.com> wrote:
>> 
>> >On Saturday, June 17, 2017 at 10:16:07 PM UTC-7, robert...@yahoo.com wrote:
>> >> On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
>> >> <dkleinecke@gmail.com> wrote:
>> >> 
>> >> >In section 5.1.2.1 of the C90 standard it says:
>> >> >   In a freestanding environment (in which C program 
>> >> >   execution may take place without any benefit of an
>> >> >   operating system), the name and type of the function
>> >> >   called at program startup are implementation-defined.
>> >> >   There are otherwise no reserved external identifiers.
>> >> >   Any library facilities to a free-standing program
>> >> >   are implementation-defined.
>> >> >
>> >> >It is actually possible to create a non-trivial program
>> >> >of this sort without any library support.
>> >> >
>> >> >Non-trivial to exclude
>> >> >
>> >> >   int main (void) {
>> >> >      return 0;}
>> >> >
>> >> >and the like. I have toyed with memory-addressed i/o but
>> >> >I think the i/o addresses must be additional reserved 
>> >> >external identifiers. 
>> >> 
>> >> 
>> >> Why would you think memory mapped I/O addresses need to be reserved
>> >> identifiers?  If the serial port is at 0xf120, and the write register
>> >> is at +1, you might well send a character by executing:
>> >> 
>> >>   *(((unsigned char *)0xf120)+1) = 'A';
>> >> 
>> >> (Tossing a "volatile" in there might be a good idea).
>> >> 
>> >> In any event, just because the standard reserves no external
>> >> identifiers in the case of a freestanding implementation, doesn't mean
>> >> there aren't some/many used by the implementation.
>> >
>> >I am not making myself perfectly clear. This is in part because
>> >the standard is not perfectly clear. So I may be using the wrong
>> >names for things. 
>> >
>> >As for your example IMO the 0xf120 is a piece of information
>> >that the hosting environment must supply and therefore must
>> >be implemented as the value of a reserved external identifier
>> >(if that phrase means information supplied to the program by  
>> >its host).
>> 
>> 
>> I think that usually a reserved external identifier would be something
>> like errno or strcmp.  See section 7.1.3 (that's the spot in the C99
>> and C11 standards).
>> 
>> But for a freestanding implementation, the standard basically
>> specifies nothing about how the program might interact with its
>> environment.
>
>I think the standard requires the environment to specify
>which function in a fully-linked freestanding bundle of
>functions is where execution is to be started. 


It says very little - it doesn't even specify that there is only one
entry (IOW, there's no requirement that there be some entry point with
a control flow analogous to what happens during the invocation of
main() ), or what the parameters and/or returns might be, or that the
entry points are called only once.


>My question
>was Are there any non-trivial programs that do not demand
>further interaction with the environment?
>
>The concept I am groping for is exactly what the hosting
>environment of a free-standing C program looks like.


The standard specifies almost nothing.  Other than that, I'm clearly
not understanding the question.

For a more concrete example, one of our products has an embedded
controller.  We used a C compiler for the device's CPU, but replaced*
the CRT startup code (basically we wrote the code that started
executing at CPU reset, which then set up the C stack, cleared what
would be the BSS space, end then called a C function).  We also added
a few assembler functions to handle some things like interrupts, I/O
ports, and access to CPU control registers.

That'[s not really an uncommon scenario, although most embedded device
toolchains provide a lot of that out of the box.


*The source for the "normal" CRT was available, we used that as a base
for our version.

[toc] | [prev] | [next] | [standalone]

#112527

On Sunday, June 18, 2017 at 7:20:02 PM UTC-7, robert...@yahoo.com wrote:
> On Sun, 18 Jun 2017 14:08:52 -0700 (PDT), David Kleinecke
> <dkleinecke@gmail.com> wrote:
> 
> >On Sunday, June 18, 2017 at 12:31:49 AM UTC-7, robert...@yahoo.com wrote:
> >> On Sat, 17 Jun 2017 23:51:05 -0700 (PDT), David Kleinecke
> >> <dkleinecke@gmail.com> wrote:
> >> 
> >> >On Saturday, June 17, 2017 at 10:16:07 PM UTC-7, robert...@yahoo.com wrote:
> >> >> On Sat, 17 Jun 2017 19:58:25 -0700 (PDT), David Kleinecke
> >> >> <dkleinecke@gmail.com> wrote:
> >> >> 
> >> >> >In section 5.1.2.1 of the C90 standard it says:
> >> >> >   In a freestanding environment (in which C program 
> >> >> >   execution may take place without any benefit of an
> >> >> >   operating system), the name and type of the function
> >> >> >   called at program startup are implementation-defined.
> >> >> >   There are otherwise no reserved external identifiers.
> >> >> >   Any library facilities to a free-standing program
> >> >> >   are implementation-defined.
> >> >> >
> >> >> >It is actually possible to create a non-trivial program
> >> >> >of this sort without any library support.
> >> >> >
> >> >> >Non-trivial to exclude
> >> >> >
> >> >> >   int main (void) {
> >> >> >      return 0;}
> >> >> >
> >> >> >and the like. I have toyed with memory-addressed i/o but
> >> >> >I think the i/o addresses must be additional reserved 
> >> >> >external identifiers. 
> >> >> 
> >> >> 
> >> >> Why would you think memory mapped I/O addresses need to be reserved
> >> >> identifiers?  If the serial port is at 0xf120, and the write register
> >> >> is at +1, you might well send a character by executing:
> >> >> 
> >> >>   *(((unsigned char *)0xf120)+1) = 'A';
> >> >> 
> >> >> (Tossing a "volatile" in there might be a good idea).
> >> >> 
> >> >> In any event, just because the standard reserves no external
> >> >> identifiers in the case of a freestanding implementation, doesn't mean
> >> >> there aren't some/many used by the implementation.
> >> >
> >> >I am not making myself perfectly clear. This is in part because
> >> >the standard is not perfectly clear. So I may be using the wrong
> >> >names for things. 
> >> >
> >> >As for your example IMO the 0xf120 is a piece of information
> >> >that the hosting environment must supply and therefore must
> >> >be implemented as the value of a reserved external identifier
> >> >(if that phrase means information supplied to the program by  
> >> >its host).
> >> 
> >> 
> >> I think that usually a reserved external identifier would be something
> >> like errno or strcmp.  See section 7.1.3 (that's the spot in the C99
> >> and C11 standards).
> >> 
> >> But for a freestanding implementation, the standard basically
> >> specifies nothing about how the program might interact with its
> >> environment.
> >
> >I think the standard requires the environment to specify
> >which function in a fully-linked freestanding bundle of
> >functions is where execution is to be started. 
> 
> 
> It says very little - it doesn't even specify that there is only one
> entry (IOW, there's no requirement that there be some entry point with
> a control flow analogous to what happens during the invocation of
> main() ), or what the parameters and/or returns might be, or that the
> entry points are called only once.
> 
> 
> >My question
> >was Are there any non-trivial programs that do not demand
> >further interaction with the environment?
> >
> >The concept I am groping for is exactly what the hosting
> >environment of a free-standing C program looks like.
> 
> 
> The standard specifies almost nothing.  Other than that, I'm clearly
> not understanding the question.
> 
> For a more concrete example, one of our products has an embedded
> controller.  We used a C compiler for the device's CPU, but replaced*
> the CRT startup code (basically we wrote the code that started
> executing at CPU reset, which then set up the C stack, cleared what
> would be the BSS space, end then called a C function).  We also added
> a few assembler functions to handle some things like interrupts, I/O
> ports, and access to CPU control registers.
> 
> That'[s not really an uncommon scenario, although most embedded device
> toolchains provide a lot of that out of the box.
> 
> 
> *The source for the "normal" CRT was available, we used that as a base
> for our version.

I find 5.1.2.1 (of the C89 standard) all that the standard seems
to expect of a freestanding program. I think it can be read so
that a "program" can have multiple possible start functions and
that which is actually started is information that must be 
supplied (by an operating system in the standard's jargon). But
no other information need be supplied. My question is whether any
non-trivial program requires additional information.

[toc] | [prev] | [next] | [standalone]

#112584

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I find 5.1.2.1 (of the C89 standard) all that the standard seems
> to expect of a freestanding program. I think it can be read so
> that a "program" can have multiple possible start functions and
> that which is actually started is information that must be 
> supplied (by an operating system in the standard's jargon). But
> no other information need be supplied. My question is whether any
> non-trivial program requires additional information.

5.1.2.1 of the current C11 standard says:

    In a freestanding environment (in which C program execution
    may take place without any benefit of an operating system),
    the name and type of the function called at program startup are
    implementation-defined. Any library facilities available to a
    freestanding program, other than the minimal set required by
    clause 4, are implementation-defined.

    The effect of program termination in a freestanding environment
    is implementationdefined.

The phrase "*the* function called at program startup" seems to me to
imply that there is one such function for a given implementation.
It might not be called "main", and it might have different type
than the main function used by a hosted implementation.

On the other hand, if an implementation lets the programmer configure
the identify of the startup function, I don't think that would be
a conformance problem, as long as it's documented.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112590

On Monday, June 19, 2017 at 11:11:07 AM UTC-5, Keith Thompson wrote:
> The phrase "*the* function called at program startup" seems to me to
> imply that there is one such function for a given implementation.
> It might not be called "main", and it might have different type
> than the main function used by a hosted implementation.

There are many freestanding implementations whose purpose, in at least some
configurations, is to generate machine code for functions that can be called
from other programs the implementation knows nothing about.  There is no
reason that a collection of source files should be limited to generating code
for a single such function.

If an imple,mentation is instructed to generate machine code that will be
loaded at address 0x40001F00..0x40001FFF and may treat that range as RAM,
that it should contain two functions:

    static uint32_t counter;
    uint32_t read_and_inc_counter(void) { return counter++; }
    void set_counter(uint32_t n) { counter = n; }

and that the entry point for the first function should be at 0x40001F00 and
the second at 0x40001F04, then the concept of "program startup" would not
be unambiguously defined by the Standard.  Is each call to either function
regarded as "starting up" the program, or is only the first call to either
function considered a startup, or what?

[toc] | [prev] | [next] | [standalone]

#112595

supercat@casperkitty.com writes:
>On Monday, June 19, 2017 at 11:11:07 AM UTC-5, Keith Thompson wrote:
>> The phrase "*the* function called at program startup" seems to me to
>> imply that there is one such function for a given implementation.
>> It might not be called "main", and it might have different type
>> than the main function used by a hosted implementation.
>

>If an imple,mentation is instructed to generate machine code that will be
>loaded at address 0x40001F00..0x40001FFF and may treat that range as RAM,
>that it should contain two functions:
>
>    static uint32_t counter;
>    uint32_t read_and_inc_counter(void) { return counter++; }
>    void set_counter(uint32_t n) { counter = n; }
>
>and that the entry point for the first function should be at 0x40001F00 and
>the second at 0x40001F04, then the concept of "program startup" would not
>be unambiguously defined by the Standard.  Is each call to either function
>regarded as "starting up" the program, or is only the first call to either
>function considered a startup, or what?

What code is performing the call to either function?  How did that code
get invoked?  How is it not part of the same free-standing program?

[toc] | [prev] | [next] | [standalone]

#112615

On Monday, June 19, 2017 at 11:51:36 AM UTC-5, Scott Lurndal wrote:
> >If an imple,mentation is instructed to generate machine code that will be
> >loaded at address 0x40001F00..0x40001FFF and may treat that range as RAM,
> >that it should contain two functions:
> >
> >    static uint32_t counter;
> >    uint32_t read_and_inc_counter(void) { return counter++; }
> >    void set_counter(uint32_t n) { counter = n; }
> >
> >and that the entry point for the first function should be at 0x40001F00 and
> >the second at 0x40001F04, then the concept of "program startup" would not
> >be unambiguously defined by the Standard.  Is each call to either function
> >regarded as "starting up" the program, or is only the first call to either
> >function considered a startup, or what?
> 
> What code is performing the call to either function?  How did that code
> get invoked?  How is it not part of the same free-standing program?

The implementation would neither know nor care.  That other program might
have been written in C, assembly language, Pascal, COBOL, FORTRAN, BASIC,
or any other language, but the only things the C implementation would have
reason to care about would be what address ranges it should use, where it
should place the entry points, and how it should expect to receive arguments
and return values.  In addition, the calling program wouldn't need to know
anything about the C code aside from the address range(s) that must be
reserved for it, the entry points and how to call them, and how much stack
it "might" use (an upper bound).

[toc] | [prev] | [next] | [standalone]

#112620

supercat@casperkitty.com writes:
>On Monday, June 19, 2017 at 11:51:36 AM UTC-5, Scott Lurndal wrote:
>> >If an imple,mentation is instructed to generate machine code that will be
>> >loaded at address 0x40001F00..0x40001FFF and may treat that range as RAM,
>> >that it should contain two functions:
>> >
>> >    static uint32_t counter;
>> >    uint32_t read_and_inc_counter(void) { return counter++; }
>> >    void set_counter(uint32_t n) { counter = n; }
>> >
>> >and that the entry point for the first function should be at 0x40001F00 and
>> >the second at 0x40001F04, then the concept of "program startup" would not
>> >be unambiguously defined by the Standard.  Is each call to either function
>> >regarded as "starting up" the program, or is only the first call to either
>> >function considered a startup, or what?
>> 
>> What code is performing the call to either function?  How did that code
>> get invoked?  How is it not part of the same free-standing program?
>
>The implementation would neither know nor care.  That other program might
>have been written in C, assembly language, Pascal, COBOL, FORTRAN, BASIC,

Today, one can easily link C subroutines into programs written in
the above languages (even BASIC, depending on vendor).

The reason this works is because there is an application binary
interface (ABI) defined that allows it.   It has nothing, zero to
do with the source-level language standard.  The ABI is defined
specifically to encourage and allow interact between multiple
source-language standards.

>or any other language, but the only things the C implementation would have
>reason to care about would be what address ranges it should use, where it
>should place the entry points,

This is the function of the operating software, not the
source language compiler.

> and how it should expect to receive arguments
>and return values.  

And this is a function of the ABI, not the source language
standard.

>In addition, the calling program wouldn't need to know
>anything about the C code aside from the address range(s) that must be
>reserved for it, the entry points and how to call them, and how much stack
>it "might" use (an upper bound).

The original post referred to a "freestanding implementation" which
presupposes no operating software and complete control over the hardware
by the programmer - in which case, do what you will, C won't care.

[toc] | [prev] | [next] | [standalone]

#112653

On Monday, June 19, 2017 at 12:37:42 PM UTC-7, Scott Lurndal wrote:

> The original post referred to a "freestanding implementation" which
> presupposes no operating software and complete control over the hardware
> by the programmer - in which case, do what you will, C won't care.

Ah ha. I would consider that "complete control over the hardware
by the programmer" the information supplied by the hosting
environment (programmer plus hardware). 

[toc] | [prev] | [next] | [standalone]

#112621

supercat@casperkitty.com writes:
> On Monday, June 19, 2017 at 11:11:07 AM UTC-5, Keith Thompson wrote:
>> The phrase "*the* function called at program startup" seems to me to
>> imply that there is one such function for a given implementation.
>> It might not be called "main", and it might have different type
>> than the main function used by a hosted implementation.
>
> There are many freestanding implementations whose purpose, in at least some
> configurations, is to generate machine code for functions that can be called
> from other programs the implementation knows nothing about.  There is no
> reason that a collection of source files should be limited to generating code
> for a single such function.

The same is true for hosted implementations.

For a hosted implementation, execution begins with an implicit call to
main, which can then call other functions.  The major difference for
freestanding implementations, as described by the standard, is that the
startup function might not be called "main" and might have an arbitrary
implementation-defined type (parameters and return type).

> If an imple,mentation is instructed to generate machine code that will be
> loaded at address 0x40001F00..0x40001FFF and may treat that range as RAM,
> that it should contain two functions:
>
>     static uint32_t counter;
>     uint32_t read_and_inc_counter(void) { return counter++; }
>     void set_counter(uint32_t n) { counter = n; }
>
> and that the entry point for the first function should be at 0x40001F00 and
> the second at 0x40001F04, then the concept of "program startup" would not
> be unambiguously defined by the Standard.  Is each call to either function
> regarded as "starting up" the program, or is only the first call to either
> function considered a startup, or what?

Compiling C code to be called from other languages is certainly useful,
but it's outside the scope of the C standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112651

On Monday, June 19, 2017 at 9:11:07 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > I find 5.1.2.1 (of the C89 standard) all that the standard seems
> > to expect of a freestanding program. I think it can be read so
> > that a "program" can have multiple possible start functions and
> > that which is actually started is information that must be 
> > supplied (by an operating system in the standard's jargon). But
> > no other information need be supplied. My question is whether any
> > non-trivial program requires additional information.
> 
> 5.1.2.1 of the current C11 standard says:
> 
>     In a freestanding environment (in which C program execution
>     may take place without any benefit of an operating system),
>     the name and type of the function called at program startup are
>     implementation-defined. Any library facilities available to a
>     freestanding program, other than the minimal set required by
>     clause 4, are implementation-defined.
> 
>     The effect of program termination in a freestanding environment
>     is implementationdefined.
> 
> The phrase "*the* function called at program startup" seems to me to
> imply that there is one such function for a given implementation.
> It might not be called "main", and it might have different type
> than the main function used by a hosted implementation.
> 
> On the other hand, if an implementation lets the programmer configure
> the identify of the startup function, I don't think that would be
> a conformance problem, as long as it's documented.

That is my reading, too.

Hence where to start is externally-supplied information

[toc] | [prev] | [next] | [standalone]

#112691

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, June 19, 2017 at 9:11:07 AM UTC-7, Keith Thompson wrote:
[...]
>> 5.1.2.1 of the current C11 standard says:
>> 
>>     In a freestanding environment (in which C program execution
>>     may take place without any benefit of an operating system),
>>     the name and type of the function called at program startup are
>>     implementation-defined. Any library facilities available to a
>>     freestanding program, other than the minimal set required by
>>     clause 4, are implementation-defined.
>> 
>>     The effect of program termination in a freestanding environment
>>     is implementationdefined.
>> 
>> The phrase "*the* function called at program startup" seems to me to
>> imply that there is one such function for a given implementation.
>> It might not be called "main", and it might have different type
>> than the main function used by a hosted implementation.
>> 
>> On the other hand, if an implementation lets the programmer configure
>> the identify of the startup function, I don't think that would be
>> a conformance problem, as long as it's documented.
>
> That is my reading, too.
>
> Hence where to start is externally-supplied information

How do you get "externally-supplied" from what I wrote?  External
relative to what?

For example, a conforming freestanding implementation might say:

    The function called at program startup is named "Startup", and is
    defined as:

        void Startup(void) { /* ... */ }

and provide no mechanism to use a different startup function.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112728

On Tuesday, June 20, 2017 at 8:32:56 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, June 19, 2017 at 9:11:07 AM UTC-7, Keith Thompson wrote:
> [...]
> >> 5.1.2.1 of the current C11 standard says:
> >> 
> >>     In a freestanding environment (in which C program execution
> >>     may take place without any benefit of an operating system),
> >>     the name and type of the function called at program startup are
> >>     implementation-defined. Any library facilities available to a
> >>     freestanding program, other than the minimal set required by
> >>     clause 4, are implementation-defined.
> >> 
> >>     The effect of program termination in a freestanding environment
> >>     is implementationdefined.
> >> 
> >> The phrase "*the* function called at program startup" seems to me to
> >> imply that there is one such function for a given implementation.
> >> It might not be called "main", and it might have different type
> >> than the main function used by a hosted implementation.
> >> 
> >> On the other hand, if an implementation lets the programmer configure
> >> the identify of the startup function, I don't think that would be
> >> a conformance problem, as long as it's documented.
> >
> > That is my reading, too.
> >
> > Hence where to start is externally-supplied information
> 
> How do you get "externally-supplied" from what I wrote?  External
> relative to what?
> 
> For example, a conforming freestanding implementation might say:
> 
>     The function called at program startup is named "Startup", and is
>     defined as:
> 
>         void Startup(void) { /* ... */ }
> 
> and provide no mechanism to use a different startup function.

Then that startup is at Startup is externally-supplied
information.

By externally (in this discussion) I mean from outside the
source code itself.

[toc] | [prev] | [next] | [standalone]

#113002

David Kleinecke <dkleinecke@gmail.com> wrote:

> Then that startup is at Startup is externally-supplied
> information.
> 
> By externally (in this discussion) I mean from outside the
> source code itself.

How is that different from main()? The source code itself also doesn't
specify that main() is the startup function on a hosted implementation;
the Standard does that.

Richard

[toc] | [prev] | [next] | [standalone]

#113004

On Monday, June 26, 2017 at 8:58:59 AM UTC-7, Richard Bos wrote:
> David Kleinecke <dkleinecke@gmail.com> wrote:
> 
> > Then that startup is at Startup is externally-supplied
> > information.
> > 
> > By externally (in this discussion) I mean from outside the
> > source code itself.
> 
> How is that different from main()? The source code itself also doesn't
> specify that main() is the startup function on a hosted implementation;
> the Standard does that.

That's my point. I asked whether it was possible to
have a program without externally-supplied information.
Information supplied by the Standard is externally-
suppled (from the point of view of the source code).

[toc] | [prev] | [next] | [standalone]

#113017

David Kleinecke <dkleinecke@gmail.com> wrote:

> On Monday, June 26, 2017 at 8:58:59 AM UTC-7, Richard Bos wrote:
> > David Kleinecke <dkleinecke@gmail.com> wrote:
> > 
> > > Then that startup is at Startup is externally-supplied
> > > information.
> > > 
> > > By externally (in this discussion) I mean from outside the
> > > source code itself.
> > 
> > How is that different from main()? The source code itself also doesn't
> > specify that main() is the startup function on a hosted implementation;
> > the Standard does that.
> 
> That's my point. I asked whether it was possible to
> have a program without externally-supplied information.
> Information supplied by the Standard is externally-
> suppled (from the point of view of the source code).

In that case, it is impossible to write any program in any language,
including assembler, which doesn't require externally-supplied
information. The only thing that's left is the front panel dip-switches.

Richard

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web