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

Groups > comp.lang.c > #60265

Re: Information on compiler/parser techniques for a new C-derived programming language

Show all headers | View raw

On 04/17/2015 03:40 PM, Emiliano Gomes Padilha wrote:
> Em quinta-feira, 16 de abril de 2015 19:02:45 UTC-3, Bart  escreveu:
...
>> Of course you will need to know what specific target to compile for, but 
>> you will need to know that to generate native code anyway.
>>
>> Another way, more portable, is to generate C source code (assuming your 
>> language is different enough from C to make that worthwhile).
> 
> Yes, I thought about that, my reservations were in whether I'd be
> able  to be in complete fine-grained control in terms of word-widths of
> datatypes and pointers when outputting C code. ...

If word-widths are important to you, then whether or not C can help you
depends upon what you mean by "word" - C itself doesn't define the term.

> ... For example, in moving on
> to the Java frameset of unifying and standardizing number-types for
> every-platform-no-matter-what (say, 'byte' as always an 8-bit integer,
> can safely be C's char?, 'char' as always 16-bit integers, can safely be
> C's short??, double as always 64-bit, can safely be C's long double? And
> if I want to have a 'huge' fl-pt. type, as, say 128-bit, would it be
> possible? Are there C libs?

However, it sounds like what you're really interested in is bit-widths,
not word-widths. To put it in perspective, is there any type whose size
you'd want to be twice as big when used on a platform where the word
size was twice as big? If not, then what you're really interested in are
bit-widths.

C can help you there with the integer types: on a platform which
supports two's complement types with no padding bits of the sizes you
specify, then you can count on <stdint.h> to define [u]int8_t,
[u]int16_t, and [u]int64_t. You don't mention any 32-bit type - was that
deliberate?

Do you care about platforms which don't have support for one or more of
those types? If not, just use those types, and if someone attempts to
port your compiler to such a platform, compilation of your compiler will
fail catastrophically - which is fine - you don't care.

However, if you are interested in such platforms, what would you want to
do on them? C's <stdint.h> provides two alternatives to, for instance,
[u]int16_t: they are [u]int_least16_t, the smallest [unsigned] integer
types with at least 16 bits, and [u]int_fast16_t, the fastest [unsigned]
integer types with at least 16 bits. Those are always guaranteed to be
defined, even on machines where, for instance, a byte is 9 bits and a
word is 36 bits - in which case those types are likely to have 18 bits.
The same guarantee applies for the 8 and 64 bit versions (also for the
32 bit version, if you actually are interested in that size).

Implementations of C which pre#define the macro __STDC_IEC_559__ conform
to the requirements of Annex F, which correspond pretty closely to those
of IEC 60559:1989 (== ANSI/IEEE 754-1985). If that's the case, then
float matches IEC 60559 single format, which is 32 bits, and double
matches IEC 60559 double format, which is 64 bits. Unfortunately, the
guarantee for long double is probably too loose for your needs:

"... matches an IEC 60559 extended format,357) else a
non-IEC 60559 extended format, else the IEC 60559 double format.
Any non-IEC 60559 extended format used for the long double type shall
have more precision than IEC 60559 double and at least the range of IEC
60559 double." (F.2p1). Note that it is not stated which extended format
is used. Given how few constraints there are on IEC 60559 extended
formats, you're probably not interested in using an unspecified member
of that set.

If you want your language to be implementable on platforms which don't
support IEC 60559:1989, you're on your own. On such platforms, C
provides too few useful guarantees about floating point operation for
such operations to be usable. A fully conforming implementation of C
which does NOT pre#define __STDC_IEC_559__ is allowed to tell you that
LDBL_MIN-LDBL_MAX > LDBL_MAX-LDBL_MIN (5.2.4.2.2p6).

The most portable way to ensure support for float and double precision
types of those sizes is to emulate floating point using software,
working on underlying data of integer types. This would require a huge
amount of work on your part, and would be absurdly slow, but has the
advantage that you would have complete control over the precision of the
results.

> I'm also thinking on a 'real' type that would use decimal representation (not binary), so it would encompass both the needs of 'decimal' and 'bignum' types in other langugages. By default it'd be a long/double sized (64-bit) with 7 bytes used for the significand in decimal and one byte for exponent and sign (giving up to 14 decimal digits in BCD plus +-63 of exponent plus the number's sign).
> If you'd make it unsigned:  +real x = 2.45;  then the exponent can be +-127
> If you'd make the exponent unsigned:  real(+) x = 1e24;  then you'd have only positive exponents (and 0) which means the number would be always integer (of a fixed maximum # of digits).
> 
> Of course, you could specify an arbitrary size of digits like an array:
> 
> real(50) x;   /*would specify capability to hold up to 50 decimal digits
>              then it won't be a 64-bit anymore as the default, but would
>              allocate, like an array, enough for all these, say 24 bytes
>              at least plus an exponent of 16-bit size or more for alignement
> */
> There are other cases, like to have a "less-fast" version in which 64-bit could hold up to 16 decimal digits plus exponent (since in fact only 7-bits are needed to represent 2 decimal digits (00 to 99), so the extra bit in every byte can make up the exponent... etc.
> 
> These are just some concepts I'm dawdling with that I'm not sure I could represent in C.

C provides no native types that work that way - but it provides tools
you could use to emulate them in software. If you're interested in
targeting a platform which has hardware support for such a type, you
wouldn't want to use such an emulation for that platform.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-16 13:26 -0700
  Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-16 23:02 +0100
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 12:40 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-17 16:36 -0400
        Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:04 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-18 22:53 -0400
            Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-22 13:07 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-18 23:14 -0500
      Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-18 14:34 +0100
  Re: Information on compiler/parser techniques for a new C-derived programming language Richard Damon <Richard@Damon-Family.org> - 2015-04-16 20:59 -0400
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 13:33 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language James Kuyper <jameskuyper@verizon.net> - 2015-04-17 16:59 -0400
  Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-16 23:02 -0500
    Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-17 10:55 +0200
      Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:48 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-18 21:55 +0200
          Re: Information on compiler/parser techniques for a new C-derived programming language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-19 11:39 +0000
            Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-19 12:48 +0100
              Re: Information on compiler/parser techniques for a new C-derived programming language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-19 14:07 +0000
            Re: Information on compiler/parser techniques for a new C-derived programming language David Brown <david.brown@hesbynett.no> - 2015-04-19 23:26 +0200
        Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-19 12:28 +0100
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 14:41 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language Robert Wessel <robertwessel2@yahoo.com> - 2015-04-17 18:41 -0500
        Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 11:30 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:37 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:44 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 03:59 -0700
  Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 02:38 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 02:54 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-18 12:43 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 13:56 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-19 00:43 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-19 01:18 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-22 13:39 -0700
            Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-22 22:28 +0100
              Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-28 13:28 -0700
                Re: Information on compiler/parser techniques for a new C-derived programming language Bartc <bc@freeuk.com> - 2015-04-28 21:55 +0100
            Re: Information on compiler/parser techniques for a new C-derived programming language Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-22 23:21 +0100
            Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-24 00:27 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 01:09 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 11:29 -0700
  Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 03:16 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 03:38 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 06:32 -0500
        Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 05:11 -0700
          Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 07:33 -0500
            Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 06:02 -0700
              Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-17 11:56 -0500
                Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-17 16:15 -0700
                Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 10:40 -0700
                Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-26 10:47 -0700
                Re: Information on compiler/parser techniques for a new C-derived programming language Morris Dovey <mrdovey@iedu.com> - 2015-04-26 13:49 -0500
  Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-17 11:17 -0700
  Re: Information on compiler/parser techniques for a new C-derived programming language Melzzzzz <mel@zzzzz.com> - 2015-04-18 05:34 +0200
  Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-17 23:18 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-20 09:39 -0700
      Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-20 23:11 -0700
        Re: Information on compiler/parser techniques for a new C-derived programming language luser droog <luser.droog@gmail.com> - 2015-04-25 21:41 -0700
  Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 04:59 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 05:16 -0700
    Re: Information on compiler/parser techniques for a new C-derived programming language fir <profesor.fir@gmail.com> - 2015-04-18 05:43 -0700

csiph-web