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

Groups > comp.lang.c > #60316

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

Show all headers | View raw

On 17/04/2015 20:40, Emiliano Gomes Padilha wrote:
> Em quinta-feira, 16 de abril de 2015 19:02:45 UTC-3, Bart  escreveu:

>> But you can save a lot of effort to start with by generating assembly
>> source code, then using an assembler to convert that into object files.
>
> Umm, thanks, I wasn't thinking on assemblers, I'm checking out: found Nasm for Windows and Linux, and infos on the Mach-O format of Mac OSX...

I have my own compiler project and it generates Nasm-compatible x86 or 
x64 source code. Nasm is invoked with -fwin32 or -fwin64. The resulting 
object files are linked with gcc's linker.

It works fine, except Nasm is a little slow (but there are other faster 
assemblers), and I don't have the satisfaction of a self-contained, 
independent compiler.

(I have generated machine code in the past, but it was easier to be 
'self-sufficient' then because I didn't rely on external libraries, only 
the OS. I didn't even bother with a 'linker', I just had a very fast 
loader.)

>> 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. 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?
>
> My idea is that the types 'd be all signed, but you could make them unsigned with +byte, +char, +int, +long, +float, +double, +huge. (this I'll probably not be able to implement for a while with floats/doubles/huges...) The + prefixed unary operator also would exist for 'unsigning' data: +(byte)-1 == 255
>
> 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.

No, those are straightforward to use C for. I've played with compilers 
generating C source, but the sort of things I wanted to do were 
genuinely difficult (manipulating the hardware stack for example), 
although I'm happy to sacrifice some features in order for C to take 
over the headache of supporting multiple platforms and deal with object 
files and linking and so on.

In the case of your real(50) type, that would be easy to support in 
manually coded C, but using user data types, function calls and so on. 
But it wouldn't integrate easily into the standard types.

But since you are generating C code, this stuff would be transparent to 
the programmer coding in your language. They will write:

  real(50) x,y,z;

  x = y+x;

and the C generated can be a mess of function calls and memory 
management. It doesn't matter. But you wanted, say, a 50-bit real type, 
C would have difficulty, but so would native code if there is no 
hardware support.

-- 
Bartc

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