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

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

Which lean C compiler for 32-bit OS development

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

Contents

  Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 01:22 -0800
    Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-12 10:36 +0100
      Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 02:09 -0800
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-12 11:37 +0100
          Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 08:02 -0800
            Re: Which lean C compiler for 32-bit OS development Borax Man <rotflol2@hotmail.com> - 2011-11-13 10:24 +1100
            Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 10:29 +0100
          Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-12 15:06 -0700
      Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-12 22:43 -0600
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-14 21:57 +0100
          Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:16 +1300
          Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-19 22:59 -0600
            Re: Which lean C compiler for 32-bit OS development "BartC" <bc@freeuk.com> - 2011-11-20 12:58 +0000
              Re: Which lean C compiler for 32-bit OS development Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> - 2011-11-21 07:30 +0100
                Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-21 01:01 -0600
              Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-21 00:51 -0600
              Re: Which lean C compiler for 32-bit OS development Brian <nospam@nospam.com> - 2011-11-22 16:47 +0000
                Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-11-22 12:10 -0500
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-22 20:24 +0100
                Re: Which lean C compiler for 32-bit OS development Richard Sanders <lnr729@gmail.com> - 2011-11-22 10:58 -0800
                  Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-24 00:27 -0800
                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-22 20:13 +0100
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-23 23:13 +0100
                Re: Which lean C compiler for 32-bit OS development Friedrich Dominicus <just-for-news-frido@q-software-solutions.de> - 2011-11-23 06:28 +0100
                  Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-23 02:45 -0800
                    Re: Which lean C compiler for 32-bit OS development Willem <willem@toad.stack.nl> - 2011-11-23 10:57 +0000
                      Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-24 01:31 -0800
                Re: Which lean C compiler for 32-bit OS development "BartC" <bc@freeuk.com> - 2011-11-23 10:58 +0000
                Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-24 00:26 -0800
      Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 01:33 -0800
        Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-11-14 17:13 +0000
          Re: Which lean C compiler for 32-bit OS development Joe Wright <joewwright@comcast.net> - 2011-11-14 14:36 -0500
          Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:56 -0800
    Re: Which lean C compiler for 32-bit OS development Nobody <nobody@nowhere.com> - 2011-11-13 02:59 +0000
      Re: Which lean C compiler for 32-bit OS development Joe Wright <joewwright@comcast.net> - 2011-11-12 22:13 -0500
        Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-13 00:03 -0600
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-14 21:55 +0100
          Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:56 -0800
          Re: Which lean C compiler for 32-bit OS development ImpalerCore <jadill33@gmail.com> - 2011-11-15 07:05 -0800
            Re: Which lean C compiler for 32-bit OS development Keith Thompson <kst-u@mib.org> - 2011-11-15 14:42 -0800
              Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-16 00:17 +0100
              Re: Which lean C compiler for 32-bit OS development ImpalerCore <jadill33@gmail.com> - 2011-11-15 17:50 -0800
      Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-12 20:38 -0700
        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-13 00:00 -0800
          Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-13 01:23 -0700
          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-11-13 09:10 +0000
            Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 10:33 +0100
              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-11-13 23:03 +1300
                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 11:17 +0100
            Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 11:29 -0800
              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 09:57 +1300
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 14:26 -0800
                  Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 11:38 +1300
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 16:01 -0800
                      Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 13:18 +1300
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-10 22:50 -0600
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 11:25 -0800
                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-11 03:45 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:06 -0800
                          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:02 +0000
                            Re: Which lean C compiler for 32-bit OS development John Tsiombikas <nuclear@member.fsf.org> - 2011-12-13 06:28 +0000
                              Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-13 00:32 -0600
                                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-12-13 10:57 +0100
                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 23:20 +0000
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:38 -0800
                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:15 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 13:51 -0800
                          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 22:32 +0000
                            Re: Which lean C compiler for 32-bit OS development John Tsiombikas <nuclear@member.fsf.org> - 2011-12-13 06:40 +0000
                              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-13 09:19 +0000
                              Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-17 00:52 -0800
                            Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-14 13:00 -0800
                              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-14 21:53 +0000
                              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-15 11:18 +1300
                                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:16 -0800
                                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-15 19:35 +0000
                                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 13:03 -0800
                                    Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-16 03:55 -0800
                                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-16 19:50 +0000
                      Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 16:54 -0600
                      Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-13 12:03 +1300
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 17:19 -0600
                          Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:52 -0800
                      Re: Which lean C compiler for 32-bit OS development Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-12 18:34 -0500
                        Re: Which lean C compiler for 32-bit OS development "io_x" <a@b.c.invalid> - 2011-12-13 09:43 +0100
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:33 -0800
              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 21:13 +0000
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 15:10 -0800
                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 23:31 +0000
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-12-11 01:57 +0100
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 11:46 -0800
                      Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 15:23 -0500
                        Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:02 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 14:00 -0800
                          Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 17:24 -0500
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 17:06 -0600
                          Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 18:16 -0500
              Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-11 09:03 -0500
                Re: Which lean C compiler for 32-bit OS development 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-11 08:57 -0800
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:11 -0800
                  Re: Which lean C compiler for 32-bit OS development Keith Thompson <kst-u@mib.org> - 2011-12-12 14:25 -0800
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-14 13:44 -0800
    Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-12 22:42 -0600

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#13445

Le 15/11/11 23:42, Keith Thompson a écrit :
>
> Under MinGW, installed from scratch on Windows 7 just a few minutes
> ago,, with gcc 4.6.1, the same program produces this output:
>
> float: 4 bytes, double: 8 bytes, long double: 12 bytes
> f  = 123.456
> d  = 123.456
> ld = -6.41666e+264
>
> Can you try this program on your system?
>

Try long long, it is bugged too.
That's why I rewrote printf from scratch.

And added all missing C99 functions lke the ones for setting
unsetting floating point precision, etc.

Years of work.

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

#13450

On Nov 15, 5:42 pm, Keith Thompson <ks...@mib.org> wrote:
> ImpalerCore <jadil...@gmail.com> writes:
>
> [...]
>
> > Actually, I recently just blew away my MinGW and reinstalled
> > everything.  In the latest version of GCC (4.6.1), the C99 printf
> > modifiers appear to work.  Not sure what they changed, but it appears
> > that some workaround has been integrated into the MinGW toolchain.
>
> Interesting.  I just did the same thing, and it still doesn't work
> correctly.
>
> Under Cygwin, this program:
>
> #include <stdio.h>
> int main(void) {
>     float f        = 123.456;
>     double d       = 123.456;
>     long double ld = 123.456;
>
>     printf("float: %d bytes, double: %d bytes, long double: %d bytes\n",
>            (int)sizeof (float),
>            (int)sizeof (double),
>            (int)sizeof (long double));
>     printf("f  = %g\n",   f);
>     printf("d  = %g\n",   d);
>     printf("ld = %Lg\n", ld);
>     return 0;
>
> }
>
> produces this (correct) output:
>
> float: 4 bytes, double: 8 bytes, long double: 12 bytes
> f  = 123.456
> d  = 123.456
> ld = 123.456
>
> Under MinGW, installed from scratch on Windows 7 just a few minutes
> ago,, with gcc 4.6.1, the same program produces this output:
>
> float: 4 bytes, double: 8 bytes, long double: 12 bytes
> f  = 123.456
> d  = 123.456
> ld = -6.41666e+264
>
> Can you try this program on your system?

I get the same result as you.  It seems that their 'long double'
modifier is still broken.  Still, I raised an eyebrow when %zu, %td,
%llu, and %lld started working.

\code
#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#include <inttypes.h>

int main( void )
{
  printf( "
------------------------------------------------------------------------
\n" );
  printf( "|        type        | specifier |     limit     |
value         |\n" );
  printf( "
------------------------------------------------------------------------
\n" );

  printf( "  %-18s   %-9s   %-13s   %"  PRId8  "\n",
          "int8_t", PRId8, "INT8_MIN", INT8_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  PRId8  "\n",
          "", "", "INT8_MAX", INT8_MAX );

  printf( "  %-18s   %-9s   %-13s   %"  PRId16  "\n",
          "int16_t", PRId16, "INT16_MIN", INT16_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  PRId16  "\n",
          "", "", "INT16_MAX", INT16_MAX );

  printf( "  %-18s   %-9s   %-13s   %"  PRId32  "\n",
          "int32_t", PRId32, "INT32_MIN", INT32_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  PRId32  "\n",
          "", "", "INT32_MAX", INT32_MAX );

#if defined(INT64_MIN)
  printf( "  %-18s   %-9s   %-13s   %"  PRId64  "\n",
          "int64_t", PRId64, "INT64_MIN", INT64_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  PRId64  "\n",
          "", "", "INT64_MAX", INT64_MAX );
#endif

  printf( "  %-18s   %-9s   %-13s   %"  PRIu8  "\n",
          "uint8_t", PRIu8, "UINT8_MAX", UINT8_MAX );
  printf( "  %-18s   %-9s   %-13s   %"  PRIu16  "\n",
          "uint16_t", PRIu16, "UINT16_MAX", UINT16_MAX );
  printf( "  %-18s   %-9s   %-13s   %"  PRIu32  "\n",
          "uint32_t", PRIu32, "UINT32_MAX", UINT32_MAX );
#if defined(UINT64_MAX)
  printf( "  %-18s   %-9s   %-13s   %"  PRIu64  "\n",
          "uint64_t", PRIu64, "UINT64_MAX", UINT64_MAX );
#endif

  printf( "  %-18s   %-9s   %-13s   %"  PRIdMAX  "\n",
          "intmax_t", PRIdMAX, "INTMAX_MIN", INTMAX_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  PRIdMAX  "\n",
          "", "", "INTMAX_MAX", INTMAX_MAX );
  printf( "  %-18s   %-9s   %-13s   %"  PRIuMAX  "\n",
          "uintmax_t", PRIuMAX, "UINTMAX_MAX", UINTMAX_MAX );

#if defined(LLONG_MAX)
  printf( "  %-18s   %-9s   %-13s   %"  "lld"  "\n",
          "long long", "lld", "LLONG_MIN", LLONG_MIN );
  printf( "  %-18s   %-9s   %-13s   %"  "lld"  "\n",
          "", "", "LLONG_MAX", LLONG_MAX );
  printf( "  %-18s   %-9s   %-13s   %"  "llu"  "\n",
          "unsigned long long", "llu", "ULLONG_MAX", ULLONG_MAX );
#endif

  printf( "  %-18s   %-9s   %-13s   %zu\n",
          "size_t", "zu", "SIZE_MAX", SIZE_MAX );
  printf( "  %-18s   %-9s   %-13s   %td\n",
          "ptrdiff_t", "td", "PTRDIFF_MIN", PTRDIFF_MIN );
  printf( "  %-18s   %-9s   %-13s   %td\n",
          "", "", "PTRDIFF_MAX", PTRDIFF_MAX );

  return 0;
}
\endcode

Before, I would get incorrect results for zu, td, llu and lld.  Now
they seem to be working.

 
------------------------------------------------------------------------
|        type        | specifier |     limit     |
value         |
 
------------------------------------------------------------------------
  int8_t               d           INT8_MIN        -128
                                   INT8_MAX        127
  int16_t              d           INT16_MIN       -32768
                                   INT16_MAX       32767
  int32_t              d           INT32_MIN       -2147483648
                                   INT32_MAX       2147483647
  int64_t              I64d        INT64_MIN
-9223372036854775808
                                   INT64_MAX       9223372036854775807
  uint8_t              u           UINT8_MAX       255
  uint16_t             u           UINT16_MAX      65535
  uint32_t             u           UINT32_MAX      4294967295
  uint64_t             I64u        UINT64_MAX
18446744073709551615
  intmax_t             I64d        INTMAX_MIN
-9223372036854775808
                                   INTMAX_MAX      9223372036854775807
  uintmax_t            I64u        UINTMAX_MAX
18446744073709551615
  long long            lld         LLONG_MIN
-9223372036854775808
                                   LLONG_MAX       9223372036854775807
  unsigned long long   llu         ULLONG_MAX
18446744073709551615
  size_t               zu          SIZE_MAX        4294967295
  ptrdiff_t            td          PTRDIFF_MIN     -2147483648
                                   PTRDIFF_MAX     2147483647

Best regards,
John D.

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

#13227

On 11/12/2011 7:59 PM, Nobody wrote:
> On Sat, 12 Nov 2011 01:22:45 -0800, James Harris wrote:
>
>> gcc is good on Unix but looks very complex to port and I think it needs
>> Cygwin on Windows.
>
> It doesn't. MinGW is the standard "native" Windows port of gcc. The
> standard 32-bit DOS port of gcc is DJGPP.
>

however, getting GCC built from sources is still fairly difficult IME, 
which could make it extra difficult to port to a new OS.

another downside is that it is often built in a form customized for a 
particular target OS, meaning that using it as a cross compiler may 
require building it from sources, and dealing with the usual hassles of 
getting it built.

however, certain common combinations are fairly easy to get pre-built, 
for example MinGW is available prebuilt on many Linux distros (as well 
as its use on Windows), so if one is looking to cross-compile for an 
environment using x86 and PE/COFF, then one may well be in luck.

typically, support for raw binaries is also available (in most GCC 
builds I have seen), although I wouldn't "generally" recommend using raw 
binaries without good reason.


it is also a fairly large and complex codebase (and difficult to make 
sense out of).

also, some (many) people (myself included) find the GAS syntax to be 
rather nasty (I personally much prefer Intel/NASM/... style syntax).

I am not certain if there is a way to get GCC to produce Intel-style 
output (I think there may be, but I haven't really looked into it).


I also have my own C compiler, although I rather doubt it would be what 
you are looking for (it is designed for JIT and working mostly in the 
context of a VM, rather than producing statically-compiled standalone 
code, and is also very buggy and is not well maintained at present...).


or such...

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

#13235

On Nov 13, 3:38 am, BGB <cr88...@hotmail.com> wrote:

...

> >> gcc is good on Unix but looks very complex to port and I think it needs
> >> Cygwin on Windows.
>
> > It doesn't. MinGW is the standard "native" Windows port of gcc. The
> > standard 32-bit DOS port of gcc is DJGPP.
>
> however, getting GCC built from sources is still fairly difficult IME,
> which could make it extra difficult to port to a new OS.
>
> another downside is that it is often built in a form customized for a
> particular target OS, meaning that using it as a cross compiler may
> require building it from sources, and dealing with the usual hassles of
> getting it built.

Do you know what would be needed in a new OS for it to run gcc? I've
never looked into it but I presume at least a clib for that OS would
be required. (The new kernel is not intended to support Unix system
calls, at least natively, though I could add a translation layer.)

> however, certain common combinations are fairly easy to get pre-built,
> for example MinGW is available prebuilt on many Linux distros (as well
> as its use on Windows), so if one is looking to cross-compile for an
> environment using x86 and PE/COFF, then one may well be in luck.

A few people have mentioned MinGW. The whole gcc thing is bulky but I
do like some of the code generation options it has such as pic, omit
frame pointer and various optimisations. I'd still rather define the
calling conventions myself but that's not something C programmers
typically want to do so is a bit off topic here.

> typically, support for raw binaries is also available (in most GCC
> builds I have seen), although I wouldn't "generally" recommend using raw
> binaries without good reason.
>
> it is also a fairly large and complex codebase (and difficult to make
> sense out of).
>
> also, some (many) people (myself included) find the GAS syntax to be
> rather nasty (I personally much prefer Intel/NASM/... style syntax).

Me too.

> I am not certain if there is a way to get GCC to produce Intel-style
> output (I think there may be, but I haven't really looked into it).

gcc has had the -masm switch added to generate asm output in something
closer to Intel syntax. At least the operands end up in Intel order.

> I also have my own C compiler, although I rather doubt it would be what
> you are looking for (it is designed for JIT and working mostly in the
> context of a VM, rather than producing statically-compiled standalone
> code, and is also very buggy and is not well maintained at present...).

Yes, different requirements. Of the non-gcc compilers I've found so
far tcc looks most promising for being small and simple. Its object
code is far from optimised, though, (and is also in gas format).

James

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

#13236

On 11/13/2011 1:00 AM, James Harris wrote:
> On Nov 13, 3:38 am, BGB<cr88...@hotmail.com>  wrote:
>
> ...
>
>>>> gcc is good on Unix but looks very complex to port and I think it needs
>>>> Cygwin on Windows.
>>
>>> It doesn't. MinGW is the standard "native" Windows port of gcc. The
>>> standard 32-bit DOS port of gcc is DJGPP.
>>
>> however, getting GCC built from sources is still fairly difficult IME,
>> which could make it extra difficult to port to a new OS.
>>
>> another downside is that it is often built in a form customized for a
>> particular target OS, meaning that using it as a cross compiler may
>> require building it from sources, and dealing with the usual hassles of
>> getting it built.
>
> Do you know what would be needed in a new OS for it to run gcc? I've
> never looked into it but I presume at least a clib for that OS would
> be required. (The new kernel is not intended to support Unix system
> calls, at least natively, though I could add a translation layer.)
>

dunno, maybe the standard C runtime and some basic POSIX features?...


>> however, certain common combinations are fairly easy to get pre-built,
>> for example MinGW is available prebuilt on many Linux distros (as well
>> as its use on Windows), so if one is looking to cross-compile for an
>> environment using x86 and PE/COFF, then one may well be in luck.
>
> A few people have mentioned MinGW. The whole gcc thing is bulky but I
> do like some of the code generation options it has such as pic, omit
> frame pointer and various optimisations. I'd still rather define the
> calling conventions myself but that's not something C programmers
> typically want to do so is a bit off topic here.
>

unless there is a compelling reason, it is usually not a good idea to 
use non-standard calling conventions.


>> typically, support for raw binaries is also available (in most GCC
>> builds I have seen), although I wouldn't "generally" recommend using raw
>> binaries without good reason.
>>
>> it is also a fairly large and complex codebase (and difficult to make
>> sense out of).
>>
>> also, some (many) people (myself included) find the GAS syntax to be
>> rather nasty (I personally much prefer Intel/NASM/... style syntax).
>
> Me too.
>
>> I am not certain if there is a way to get GCC to produce Intel-style
>> output (I think there may be, but I haven't really looked into it).
>
> gcc has had the -masm switch added to generate asm output in something
> closer to Intel syntax. At least the operands end up in Intel order.
>

yeah. never really messed with it much personally...


>> I also have my own C compiler, although I rather doubt it would be what
>> you are looking for (it is designed for JIT and working mostly in the
>> context of a VM, rather than producing statically-compiled standalone
>> code, and is also very buggy and is not well maintained at present...).
>
> Yes, different requirements. Of the non-gcc compilers I've found so
> far tcc looks most promising for being small and simple. Its object
> code is far from optimised, though, (and is also in gas format).
>

yep.

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

#13237

On 2011-11-13, James Harris <james.harris.1@googlemail.com> wrote:
> A few people have mentioned MinGW. The whole gcc thing is bulky but I
> do like some of the code generation options it has such as pic, omit
> frame pointer and various optimisations. I'd still rather define the
> calling conventions myself but that's not something C programmers
> typically want to do so is a bit off topic here.

You are not looking for C at all.  You are looking for defining your own
ABI and using it on a bunch of systems.

Basically, you're Doing It Wrong.  If you want to use C, *USE C*.  Work
with the language the way it is designed, rather than trying to outsmart
it.

And that means that you don't waste valuable time and effort trying to
figure out ways to avoid recompiling on new targets, because *that is
silly*.  The entire point of C is that you can *recompile* on new targets,
not that you can make magical binaries which are portable across unrelated
targets.

Then, all the "problems" go away.  You don't care what compiler any given
target has as long as it supports the standard.  You don't care what CPU
is in use, or anything like that.  Poof!  Problem solved by using the tool
for the purpose it was designed for.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#13239

Le 13/11/11 10:10, Seebs a écrit :
>
> You are not looking for C at all.  You are looking for defining your own
> ABI and using it on a bunch of systems.
>
> Basically, you're Doing It Wrong.  If you want to use C, *USE C*.  Work
> with the language the way it is designed, rather than trying to outsmart
> it.
>

Sure, and you can't test for overflow in an efficient manner, you miss 
all the speed of assembly language and you are limited by C limitations.

And a LONG etcetera. My customers need a code generator because what 
they want to do is not C. If C would fit the bill they would use C.

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

#13240

On 11/13/11 10:33 PM, jacob navia wrote:
> Le 13/11/11 10:10, Seebs a écrit :
>>
>> You are not looking for C at all.  You are looking for defining your own
>> ABI and using it on a bunch of systems.
>>
>> Basically, you're Doing It Wrong.  If you want to use C, *USE C*.  Work
>> with the language the way it is designed, rather than trying to outsmart
>> it.
>
> Sure, and you can't test for overflow in an efficient manner, you miss
> all the speed of assembly language and you are limited by C limitations.

The fact that you have customers looking for a code generator does prove 
there is a demand.  By surely the nice is small (all be profitable)?

On my usual platform (Solaris) the native compiler with all of it's 
supporting paraphernalia will almost always generate faster applications 
than hand optimising assembly language.  I'm sure the same applies to 
other hosted environments.

-- 
Ian Collins

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

#13241

Le 13/11/11 11:03, Ian Collins a écrit :

> On my usual platform (Solaris) the native compiler with all of it's
> supporting paraphernalia will almost always generate faster applications
> than hand optimising assembly language. I'm sure the same applies to
> other hosted environments.
>

Just one example:

A 352 bit floating point. Yes, you can write that in C, but the speed
is very bad. Lcc-win's module is an order of magnitude faster. Why?

o Using add and add with carry to add 64 bit integers keeping the carry.
o Using many assembly specific instructions that the C compiler never
   uses.
o And a long etcetera.

But I notice that you said:

"almost always"

Well... :-)

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

#14451

On Nov 13, 9:10 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-11-13, James Harris <james.harri...@googlemail.com> wrote:
>
> > A few people have mentioned MinGW. The whole gcc thing is bulky but I
> > do like some of the code generation options it has such as pic, omit
> > frame pointer and various optimisations. I'd still rather define the
> > calling conventions myself but that's not something C programmers
> > typically want to do so is a bit off topic here.
>
> You are not looking for C at all.  You are looking for defining your own
> ABI and using it on a bunch of systems.

Your comments are 'robust'. I will return the compliment. :-)

You are being naive, Peter. If C is the best tool for the job it makes
sense to use it. Period. There is no point ignoring C for this task
because it is not perfect. Nothing is. C is by far the best HLL I know
of for what I want to do so it makes sense to use it.

> Basically, you're Doing It Wrong.  If you want to use C, *USE C*.  Work
> with the language the way it is designed, rather than trying to outsmart
> it.

For just about all the C programming I have ever done I have had to
interface with no other programming languages. In this project that is
not the case. The C code will have to work with code written in other
languages, if only assembler.

As things stand I will have to adjust the asm to dovetail with one of
the calling conventions of the C compiler I choose. I would *prefer*
the option to customise the compiler's output to conventions that I
select - but I recognise that may not be possible.

Taking a step back, consider a C anomaly. Look at how low-level C is
and why it is favoured as a 'portable assembler' (not a phrase I am
recommending) by compiler writers and others. In C there is usually a
clear, direct and simple correspondence between C operations and a
CPU's opcodes, and a similar correspondence between C data types and
those supported by the CPU.

However, this simple one-to-one mapping of C features to CPU features
does not apply to subroutine calls and function prologues and
epilogues. In this case (like no other in the language?) C generates a
slew of instructions for one source language construct. I understand
why and agree with the choice. C was meant to interface with C.
However, it is a distinct difference in the level of the language. I
was commenting on the lack of control over this part of the object
code.

> And that means that you don't waste valuable time and effort trying to
> figure out ways to avoid recompiling on new targets, because *that is
> silly*.  The entire point of C is that you can *recompile* on new targets,
> not that you can make magical binaries which are portable across unrelated
> targets.

You misunderstand. I was not talking about avoiding recompilation. I
was talking, in part, about interfacing C with non-C.

> Then, all the "problems" go away.  You don't care what compiler any given
> target has as long as it supports the standard.  You don't care what CPU
> is in use, or anything like that.  Poof!  Problem solved by using the tool
> for the purpose it was designed for.

This is true for most C programming but if you are saying this is
universally true I don't agree. In my case the OS has distinct address
space, tasking and resource models. This is the other part of what I
was talking about: interfacing C with the desired OS models. So I *do*
care what the compiler generates. It matters to the goals of the
project.

James

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

#14452

On 12/11/11 08:29 AM, James Harris wrote:
> On Nov 13, 9:10 am, Seebs<usenet-nos...@seebs.net>  wrote:
>
> For just about all the C programming I have ever done I have had to
> interface with no other programming languages. In this project that is
> not the case. The C code will have to work with code written in other
> languages, if only assembler.
>
> As things stand I will have to adjust the asm to dovetail with one of
> the calling conventions of the C compiler I choose. I would *prefer*
> the option to customise the compiler's output to conventions that I
> select - but I recognise that may not be possible.

You haven't really said what you are trying to do.  Are you targeting a 
hosted platform?  If so the function call ABI will already be well defined.

> Taking a step back, consider a C anomaly. Look at how low-level C is
> and why it is favoured as a 'portable assembler' (not a phrase I am
> recommending) by compiler writers and others. In C there is usually a
> clear, direct and simple correspondence between C operations and a
> CPU's opcodes, and a similar correspondence between C data types and
> those supported by the CPU.

Once upon a time long ago, maybe.  This certainly isn't the case today.

> However, this simple one-to-one mapping of C features to CPU features
> does not apply to subroutine calls and function prologues and
> epilogues. In this case (like no other in the language?) C generates a
> slew of instructions for one source language construct. I understand
> why and agree with the choice. C was meant to interface with C.
> However, it is a distinct difference in the level of the language. I
> was commenting on the lack of control over this part of the object
> code.

The "lack of control" is because the function call ABI is defined for 
the platform/CPU outside of the C standard.  To invent some arbitrary 
ABI that does not conform with the host is pointless.

>> And that means that you don't waste valuable time and effort trying to
>> figure out ways to avoid recompiling on new targets, because *that is
>> silly*.  The entire point of C is that you can *recompile* on new targets,
>> not that you can make magical binaries which are portable across unrelated
>> targets.
>
> You misunderstand. I was not talking about avoiding recompilation. I
> was talking, in part, about interfacing C with non-C.

Which is often define in the "non C" language specification.

>> Then, all the "problems" go away.  You don't care what compiler any given
>> target has as long as it supports the standard.  You don't care what CPU
>> is in use, or anything like that.  Poof!  Problem solved by using the tool
>> for the purpose it was designed for.
>
> This is true for most C programming but if you are saying this is
> universally true I don't agree. In my case the OS has distinct address
> space, tasking and resource models. This is the other part of what I
> was talking about: interfacing C with the desired OS models. So I *do*
> care what the compiler generates. It matters to the goals of the
> project.

So you you are using an OS without a well defined ABI?

-- 
Ian Collins

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

#14459

On Dec 10, 8:57 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 08:29 AM, James Harris wrote:

...

> You haven't really said what you are trying to do.  Are you targeting a
> hosted platform?  If so the function call ABI will already be well defined.

I did say (in the title/subject) that this is for development of an OS
- an operating system. As such, no, this is not for a hosted platform.
The 'platform' itself is being defined, as is the ABI.

> > Taking a step back, consider a C anomaly. Look at how low-level C is
> > and why it is favoured as a 'portable assembler' (not a phrase I am
> > recommending) by compiler writers and others. In C there is usually a
> > clear, direct and simple correspondence between C operations and a
> > CPU's opcodes, and a similar correspondence between C data types and
> > those supported by the CPU.
>
> Once upon a time long ago, maybe.  This certainly isn't the case today.

I don't understand but am interested in the idea. What has changed to
make this no longer the case?

> > However, this simple one-to-one mapping of C features to CPU features
> > does not apply to subroutine calls and function prologues and
> > epilogues. In this case (like no other in the language?) C generates a
> > slew of instructions for one source language construct. I understand
> > why and agree with the choice. C was meant to interface with C.
> > However, it is a distinct difference in the level of the language. I
> > was commenting on the lack of control over this part of the object
> > code.
>
> The "lack of control" is because the function call ABI is defined for
> the platform/CPU outside of the C standard.  To invent some arbitrary
> ABI that does not conform with the host is pointless.

As the OS is new there is no host software at all. The OS's use of the
CPU is fairly generic and could apply to various processors. So all of
the structure and interface is up for definition.

...

> > In my case the OS has distinct address
> > space, tasking and resource models. This is the other part of what I
> > was talking about: interfacing C with the desired OS models. So I *do*
> > care what the compiler generates. It matters to the goals of the
> > project.
>
> So you you are using an OS without a well defined ABI?

Well, the interface to the OS will be well defined but the design is
intended to be based on first principles and, as far as possible, to
avoid influence from existing systems.

Sorry to be vague about the OS internals. They are well off-topic for
c.l.c.

James

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

#14460

On 12/11/11 11:26 AM, James Harris wrote:
> On Dec 10, 8:57 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 12/11/11 08:29 AM, James Harris wrote:
>
> ....
>
>> You haven't really said what you are trying to do.  Are you targeting a
>> hosted platform?  If so the function call ABI will already be well defined.
>
> I did say (in the title/subject) that this is for development of an OS
> - an operating system. As such, no, this is not for a hosted platform.
> The 'platform' itself is being defined, as is the ABI.

Well that clarifies things.  You would still be well advised to follow 
existing practice for your ABI.  If nothing else, that will simplify 
writing a gcc port for your platform.  For some processors (AMD64, 
Sparc) calling conventions are well defined.

>>> Taking a step back, consider a C anomaly. Look at how low-level C is
>>> and why it is favoured as a 'portable assembler' (not a phrase I am
>>> recommending) by compiler writers and others. In C there is usually a
>>> clear, direct and simple correspondence between C operations and a
>>> CPU's opcodes, and a similar correspondence between C data types and
>>> those supported by the CPU.
>>
>> Once upon a time long ago, maybe.  This certainly isn't the case today.
>
> I don't understand but am interested in the idea. What has changed to
> make this no longer the case?

Optimisation technology.

-- 
Ian Collins

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

#14466

On Dec 10, 10:38 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 11:26 AM, James Harris wrote:
>
> > On Dec 10, 8:57 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 12/11/11 08:29 AM, James Harris wrote:
>
> > ....
>
> >> You haven't really said what you are trying to do.  Are you targeting a
> >> hosted platform?  If so the function call ABI will already be well defined.
>
> > I did say (in the title/subject) that this is for development of an OS
> > - an operating system. As such, no, this is not for a hosted platform.
> > The 'platform' itself is being defined, as is the ABI.
>
> Well that clarifies things.

Great.

> You would still be well advised to follow
> existing practice for your ABI.  If nothing else, that will simplify
> writing a gcc port for your platform.

I understand the point. However, from what I have done so far I can
see it would be easy to miss useful innovations by being influenced by
existing systems. The whole point of writing a new OS is to do things
in a new way. So my intention is as far as possible to make a clean
design and then to provide interfacing as needed.

If I can wax lyrical for a moment: How often does a programmer get to
write something that is totally independent of existing systems?
Almost never. We work with specific operating systems such as Unix,
Windows, DOS etc. We work with specific libraries such as sockets and
various GUIs and we work with specific file formats such as Elf, jpeg
etc. And we work with specific concepts such as files and data
streams. *All* of these are up for grabs when writing an OS.

If anyone is interested in looking at this there is some info at

  http://aodfaq.wikispaces.com/

put together by a bunch of people doing similar.

> For some processors (AMD64,
> Sparc) calling conventions are well defined.


> >>> Taking a step back, consider a C anomaly. Look at how low-level C is
> >>> and why it is favoured as a 'portable assembler' (not a phrase I am
> >>> recommending) by compiler writers and others. In C there is usually a
> >>> clear, direct and simple correspondence between C operations and a
> >>> CPU's opcodes, and a similar correspondence between C data types and
> >>> those supported by the CPU.
>
> >> Once upon a time long ago, maybe.  This certainly isn't the case today.
>
> > I don't understand but am interested in the idea. What has changed to
> > make this no longer the case?
>
> Optimisation technology.

I don't see this. I was talking about how C operations are those you
will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
how C's data types map to typical CPU data types: signed and unsigned
integers and bitfields of different widths, floats of differing types.
Surely these are not dependent on optimisation.

James

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

#14467

On 12/11/11 01:01 PM, James Harris wrote:
> On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 12/11/11 11:26 AM, James Harris wrote:
>
>> You would still be well advised to follow
>> existing practice for your ABI.  If nothing else, that will simplify
>> writing a gcc port for your platform.
>
> I understand the point. However, from what I have done so far I can
> see it would be easy to miss useful innovations by being influenced by
> existing systems. The whole point of writing a new OS is to do things
> in a new way. So my intention is as far as possible to make a clean
> design and then to provide interfacing as needed.

Consider this: why would the designers of an OS ABI choose an 
inefficient calling convention?

> If I can wax lyrical for a moment: How often does a programmer get to
> write something that is totally independent of existing systems?
> Almost never. We work with specific operating systems such as Unix,
> Windows, DOS etc. We work with specific libraries such as sockets and
> various GUIs and we work with specific file formats such as Elf, jpeg
> etc. And we work with specific concepts such as files and data
> streams. *All* of these are up for grabs when writing an OS.

They are also frequently up for grabs in embedded systems, where most C 
programmers operate these days.


>>> I don't understand but am interested in the idea. What has changed to
>>> make this no longer the case?
>>
>> Optimisation technology.
>
> I don't see this. I was talking about how C operations are those you
> will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> how C's data types map to typical CPU data types: signed and unsigned
> integers and bitfields of different widths, floats of differing types.
> Surely these are not dependent on optimisation.

You could say the same for any programming language.  C does allow you 
to specify exact with types, but they are provided to enable C to 
interface with low level entities.  Most C programs won't use them.

How an instance of a type is manipulated is very much dependent on 
optimisation.  A declared variable may not even exist in optimised code. 
  The machine instructions emitted by an optimising compiler often bear 
little resemblance to the code written by the programmer. Functions get 
inlined, instructions get reordered and so on.

-- 
Ian Collins

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

#14474

On Sun, 11 Dec 2011 13:18:09 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>On 12/11/11 01:01 PM, James Harris wrote:
>> On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>>> On 12/11/11 11:26 AM, James Harris wrote:
>>
>>> You would still be well advised to follow
>>> existing practice for your ABI.  If nothing else, that will simplify
>>> writing a gcc port for your platform.
>>
>> I understand the point. However, from what I have done so far I can
>> see it would be easy to miss useful innovations by being influenced by
>> existing systems. The whole point of writing a new OS is to do things
>> in a new way. So my intention is as far as possible to make a clean
>> design and then to provide interfacing as needed.
>
>Consider this: why would the designers of an OS ABI choose an 
>inefficient calling convention?


Good question, but it happens.  Both native S/360 and VAX OSs picked
painfully expensive ABIs out of some attempt at generality, VAX being
even worse, *and* partially fixed in hardware.  Part of it was
certainly an expectation that system (and subroutine) calls would be
fairly rare, these being designed in the era of monolithic programs.
On both systems compilers would often use a different (and much
lighter weight) ABI within a program, and switch to the system ABI
between modules.

And the AS/400, which largely required an entire context switch
between separately compiled programs, made both of those look
positively featherweight by comparison (although that's been fixed in
later versions).  Again, there was an  assumption of monolithic
programs.

Certainly more recent systems have made lighter weight calling
conventions much more of a priority.  Even in those cases, ABI have
tended to be pretty sticky, and unable to take advantage of ISA
changes (consider FP calling conventions on x86-32, which really don't
make sense, except in terms of backwards compatibility, in the
presence of SSE2).

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

#14507

On Dec 11, 12:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 01:01 PM, James Harris wrote:
>
> > On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 12/11/11 11:26 AM, James Harris wrote:
>
> >> You would still be well advised to follow
> >> existing practice for your ABI.  If nothing else, that will simplify
> >> writing a gcc port for your platform.
>
> > I understand the point. However, from what I have done so far I can
> > see it would be easy to miss useful innovations by being influenced by
> > existing systems. The whole point of writing a new OS is to do things
> > in a new way. So my intention is as far as possible to make a clean
> > design and then to provide interfacing as needed.
>
> Consider this: why would the designers of an OS ABI choose an
> inefficient calling convention?

There is far more to this than an ABI!

> > If I can wax lyrical for a moment: How often does a programmer get to
> > write something that is totally independent of existing systems?
> > Almost never. We work with specific operating systems such as Unix,
> > Windows, DOS etc. We work with specific libraries such as sockets and
> > various GUIs and we work with specific file formats such as Elf, jpeg
> > etc. And we work with specific concepts such as files and data
> > streams. *All* of these are up for grabs when writing an OS.
>
> They are also frequently up for grabs in embedded systems, where most C
> programmers operate these days.

OK.

Why? Is it that the embedded development market in C is so large that
it dwarfs anything done elsewhere or is it that C has been replaced
with something else for development under Unix and Windows? The latter
would be sad!

> >>> I don't understand but am interested in the idea. What has changed to
> >>> make this no longer the case?
>
> >> Optimisation technology.
>
> > I don't see this. I was talking about how C operations are those you
> > will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> > how C's data types map to typical CPU data types: signed and unsigned
> > integers and bitfields of different widths, floats of differing types.
> > Surely these are not dependent on optimisation.
>
> You could say the same for any programming language.  C does allow you
> to specify exact with types, but they are provided to enable C to
> interface with low level entities.  Most C programs won't use them.

Sure. Those types are ideal for what I want to do.

> How an instance of a type is manipulated is very much dependent on
> optimisation.  A declared variable may not even exist in optimised code.
>   The machine instructions emitted by an optimising compiler often bear
> little resemblance to the code written by the programmer. Functions get
> inlined, instructions get reordered and so on.

I understand where you were coming from now - and others have said
similar. But this is missing the point. I don't care about reorganised
code or elided operations. In terms of operations the value of C is in
being able to keep to low level concepts in the source - and be
virtually guaranteed that the generated code will be at least as
simple/fundamental.

James

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

#14472

On 2011-12-11, James Harris <james.harris.1@googlemail.com> wrote:
> I understand the point. However, from what I have done so far I can
> see it would be easy to miss useful innovations by being influenced by
> existing systems. The whole point of writing a new OS is to do things
> in a new way. So my intention is as far as possible to make a clean
> design and then to provide interfacing as needed.

Hmm.  Well, it's an interesting experiment, anyway.  I'm not sure I'd expect
it to yield significant advantages.

> If I can wax lyrical for a moment: How often does a programmer get to
> write something that is totally independent of existing systems?
> Almost never.

I have rarely *wanted* to.  Interactions with stuff is what makes things
interesting.

> I don't see this. I was talking about how C operations are those you
> will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> how C's data types map to typical CPU data types: signed and unsigned
> integers and bitfields of different widths, floats of differing types.
> Surely these are not dependent on optimisation.

For an obvious example that someone recently brought up:  Many ARM processors
lack a divider in hardware.

So there's often, for even the most primitive operations, substantial code
generation going on behind the scenes.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14510

On Dec 11, 3:45 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-12-11, James Harris <james.harri...@googlemail.com> wrote:
>
> > I understand the point. However, from what I have done so far I can
> > see it would be easy to miss useful innovations by being influenced by
> > existing systems. The whole point of writing a new OS is to do things
> > in a new way. So my intention is as far as possible to make a clean
> > design and then to provide interfacing as needed.
>
> Hmm.  Well, it's an interesting experiment, anyway.  I'm not sure I'd expect
> it to yield significant advantages.

One has to be realistic. Many innovations are devised by teams at
universities or of professionals. They have a pool of brainpower to
call on and to interact with.

However, given enough time, enthusiasm and a refusal to do something
because "that's what is done" it is surprising what can be come up
with.

> > If I can wax lyrical for a moment: How often does a programmer get to
> > write something that is totally independent of existing systems?
> > Almost never.
>
> I have rarely *wanted* to.  Interactions with stuff is what makes things
> interesting.

Oh, there are *plenty* of interactions still! It's just that one
starts with a clean slate.

I understand your point, though.

> > I don't see this. I was talking about how C operations are those you
> > will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> > how C's data types map to typical CPU data types: signed and unsigned
> > integers and bitfields of different widths, floats of differing types.
> > Surely these are not dependent on optimisation.
>
> For an obvious example that someone recently brought up:  Many ARM processors
> lack a divider in hardware.
>
> So there's often, for even the most primitive operations, substantial code
> generation going on behind the scenes.

That's OK. The main thing is to keep the source to just simple
operations, the data types to bytes and multiples of machine words,
and the structures to things which will be predictably translated into
assembler. Then there shouldn't be any unwanted surprises.

James

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

#14515

On 2011-12-12, James Harris <james.harris.1@googlemail.com> wrote:
> However, given enough time, enthusiasm and a refusal to do something
> because "that's what is done" it is surprising what can be come up
> with.

Yes.  But not always *good* surprising.  :)

>> So there's often, for even the most primitive operations, substantial code
>> generation going on behind the scenes.

> That's OK. The main thing is to keep the source to just simple
> operations, the data types to bytes and multiples of machine words,
> and the structures to things which will be predictably translated into
> assembler. Then there shouldn't be any unwanted surprises.

I've used a machine with 32-bit words and 80-bit floats.  :)

I think the fact is, there's always gonna be surprises with a good compiler,
especially with decent optimization.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

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

csiph-web