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

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

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

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

Contents

  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

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

#60174 — Information on compiler/parser techniques for a new C-derived programming language

Hi,
I'm designing a new programming language on the vein of C/C++ (I know, I know, "why are you doing that?, It's worthless, don't do that, Yet another goof, etc..").
Nevertheless, please let me pursue my "vain" effort, and anyway because I don't have experience in designing & programming parsers/interpreters/compilers (other than the long-ago class I had on Compilers in my Computer Science graduation -- I have a Msc and Phd but it's in Artificial Intelligence & Natural Language/Cognitive Science, so... very different fields of study!),

therefore I'm looking for any pointers anyone around might have on where do I start. I know I'll program a parser/interpreter and later possibly compilers (hopefully for different platforms) in C (NOT C++, I know both but I prefer to go with the basics in this "low-level" project).

My language is going to be object-oriented, threaded, functional, statically & dynamically imperative as well (yes, I KNOW what all these mean, I'm versed in programming language concepts/design, I just don't know much on the INTERNALS), so if anyone can point me to information on:

- modern parsing/optimization techniques (info and/or codes)
- look-up tables, hashing info and techniques to get the best/efficient hashing on tables of identifiers of various types (functions, basic types, objects, global/local, etc.)
- threading (I know the basic Unix's fork() call for creating new processes) but that doesn't count, does it?)

- the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)

Phew, it's a lot,
anyway, thanx on ANY info or comments...
Emiliano.

[toc] | [next] | [standalone]

#60177

On 16/04/2015 21:26, Emiliano Gomes Padilha wrote:

> I'm designing a new programming language on the vein of C/C++

> - the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)

I think they can be different even on the same platform!

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.

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).

-- 
Bartc

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

#60258

Em quinta-feira, 16 de abril de 2015 19:02:45 UTC-3, Bart  escreveu:
> I think they can be different even on the same platform!
> 
> 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...

> 
> 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. 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.

> 
> -- 
> Bartc

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

#60265

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.

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

#60331

Em sexta-feira, 17 de abril de 2015 17:36:21 UTC-3, James Kuyper  escreveu:
> 
> 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...
> 
> 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.

No, I was just referring bit-widths to set fixed sizes for numeric types, like Java does: "int and float in all platforms should be 32-bit numbers (4 bytes), long/double are always 64-bit numbers (occupying 8 bytes), etc. But I guess, probably, that won't be possible in the widest number of platforms with native compiled code as is done in C. Java is able to set fixed widths because they primarily emulate operations with their JVM...

> 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?

No, I just didn't mention 32 bits; it's the usual: int's and float's as 32-bit numbers. But, yes, it's just my ignorance of all these header files of C that I haven't looked at yet... I bet I would be able to have all the fine-control I want in C, I just have to get acquainted with all the libraries and available accessory utilities... I was reading the C++11 additions, and now it's even possible to have control of alignments with alignof and alignas, but arguably one has to know what one's doing... :)


> 
> 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).

That's perfect. Yes, it's exactly what I was looking for, just didn't know. I was aware that there were in the past systems with 9-bit bytes (non-octets) and processor words of 36-bits, but didn't know if they are still around.

> 
> 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.

Well, I guess any floating-point maths above double precision (64-bit) I will have to go with what's in existence, the available libraries or types in C or C++...
> 
> 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.

Yes, I think I'll leave that for Java (to be in complete control of a fixed-width for all platforms). I will go with the easier, more portable route of what's available in C/C++ and let them handle it...

> > I'm also thinking on a 'real' type that would use decimal representation > 
> ...
> 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.

Right, the idea is indeed the sane one that if the CPU provides their own operations, use them: I'll trust C then that it'll do it in the best way, to use the available resources on each platform.

EMiliano.

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

#60359

On 04/18/2015 02:04 PM, Emiliano Gomes Padilha wrote:
> Em sexta-feira, 17 de abril de 2015 17:36:21 UTC-3, James Kuyper  escreveu:
...
> No, I was just referring bit-widths ...

Actually, no you weren't - which was my point. The numbers you gave were
bit-widths, but the phrase you used was "word-width". I've never even
heard anyone refer to "word-width" before, which is one reason the
discrepancy caught my attention.
I'm well-known as a pedant because I think it's important to make sure
you're using the right word for the meaning you're expressing. I'm
pretty much the polar opposite of the guy who's been attracting a lot of
attention on this newsgroup recently for arguing that he didn't make a
mistake when he treated maximize as a synonym (sic!) for minimize.

...
> all the fine-control I want in C, I just have to get acquainted with all
> the libraries and available accessory utilities... I was reading the
> C++11 additions, and now it's even possible to have control of
> alignments with alignof and alignas, but arguably one has to know what
> one's doing... :)

That's right. There's many modern high-level languages out there where
it can be very rewarding to just play around with the language without
knowing what you're doing. C's not such a language. It provides too many
ways to shoot yourself in the foot.

>> 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).
> 
> That's perfect. Yes, it's exactly what I was looking for, just didn't know. I was aware that there were in the past systems with 9-bit bytes (non-octets) and processor words of 36-bits, but didn't know if they are still around.

That's a first - most of the time, when I advise people of the
possibility of unusual byte sizes, they're uninterested. They point out
the near universality of 8-bit bytes, and as a practical matter, they're
correct. No one has ever accused me of being a particularly practical
person.

I applaud you're willingness to consider that possibility, but I'd
recommend not worrying about it too much. Use the least-sized and
fast-sized types to ensure portability to oddball platforms, but
otherwise concentrate your attention on any one of the thousands of
other issues you'll have to deal with that are more urgent. Those
oddball platforms have never been common, and have, if anything, been
becoming less common.
-- 
James Kuyper

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

#60788

Em sábado, 18 de abril de 2015 23:53:24 UTC-3, James Kuyper  escreveu:
>...
>> I was aware that there were in the past systems with 9-bit bytes (non-
>>octets) and processor words of 36-bits, but didn't know if they are still
>>around.
> 
> That's a first - most of the time, when I advise people of the
> possibility of unusual byte sizes, they're uninterested. They point out
> the near universality of 8-bit bytes, and as a practical matter, they're
> correct. No one has ever accused me of being a particularly practical
> person.
> 
> I applaud you're willingness to consider that possibility, but I'd
> recommend not worrying about it too much. Use the least-sized and
> fast-sized types to ensure portability to oddball platforms, but
> otherwise concentrate your attention on any one of the thousands of
> other issues you'll have to deal with that are more urgent. Those
> oddball platforms have never been common, and have, if anything, been
> becoming less common.
> -- 
> James Kuyper

Anyone who has read K&R's "The C prog. language" would've been introduced
to the idea that 'bytes' aren't always 8-bits. And I only remember that's
where I learnt it because I recently re-browsed it to get a refresh on
some things...

Emiliano.

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

#60363

On Sat, 18 Apr 2015 11:04:53 -0700 (PDT), Emiliano Gomes Padilha
<egpadilha@gmail.com> wrote:

>Em sexta-feira, 17 de abril de 2015 17:36:21 UTC-3, James Kuyper  escreveu:

>> 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).
>
>That's perfect. Yes, it's exactly what I was looking for, just didn't know. I was aware that there were in the past systems with 9-bit bytes (non-octets) and processor words of 36-bits, but didn't know if they are still around.



Unisys' Clearpath IX line still implements the old UNIVAC 1100/2200 36
bit, ones-complement architecture, with 9 bit characters.  There is a
C89 compiler available for OS 2200.

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

#60316

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

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

#60189

On 4/16/15 4:26 PM, Emiliano Gomes Padilha wrote:
> Hi,

> I'm designing a new programming language on the vein of C/C++ (I
> know, I know, "why are you doing that?, It's worthless, don't do
> that, Yet another goof, etc.."). Nevertheless, please let me pursue
> my "vain" effort, and anyway because I don't have experience in
> designing & programming parsers/interpreters/compilers (other than
> the long-ago class I had on Compilers in my Computer Science
> graduation -- I have a Msc and Phd but it's in Artificial
> Intelligence & Natural Language/Cognitive Science, so... very
> different fields of study!),
>
> therefore I'm looking for any pointers anyone around might have on
> where do I start. I know I'll program a parser/interpreter and later
> possibly compilers (hopefully for different platforms) in C (NOT C++,
> I know both but I prefer to go with the basics in this "low-level"
> project).

Before you can really get into a parser/interpreter, you need to design 
your language (or you don't have anything to parse). If you haven't done 
a parser before, then perhaps you could start (as a learning experience) 
with a parser for an existing language.

>
> My language is going to be object-oriented, threaded, functional,
> statically & dynamically imperative as well (yes, I KNOW what all
> these mean, I'm versed in programming language concepts/design, I
> just don't know much on the INTERNALS), so if anyone can point me to
> information on:
>
> - modern parsing/optimization techniques (info and/or codes)
 > - look-up tables, hashing info and techniques to get the best/efficient
> hashing on tables of identifiers of various types (functions, basic
> types, objects, global/local, etc.)

For these two, refer to my first comment. Getting the language "right" 
is more important than getting the compiler "efficient", especially at 
the start. Yes, it is good to have an idea about what things make a 
language hard to parse, but these tend to be basics, and not dependent 
on the latest ideas of hash-tables etc.

 > - threading (I know the basic Unix's fork() call for creating new
 > processes) but that doesn't count, does it?)

Threads aren't hard to create if the OS supplies the basic api (for *nix 
look at the pthread library). Threads DO create a number of issues that 
need to be solved, and it can be difficult to get and prove that a 
program is 100% correct.
>
> - the formats and linking process of C/C++ object files/symbol tables
> (are they the same on different platforms?? Say, is the object/symbol
> table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the
> same apart from the differing machine codes?)

Different platforms can have differing object file formats. There are a 
few standard ones, but depending on how universal you want to be, you 
can run into a lot of them. You then have the issue of generating 
machine code for a number of different machines architecture.

One common method when first developing a language is to compile to some 
simpler language, C has been one common target. Once you have your 
language worked out, and the front end parsing it right, you can then 
start working on back ends to generate the output for the systems you 
want to target.
>
> Phew, it's a lot, anyway, thanx on ANY info or comments... Emiliano.
>

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

#60264

> Before you can really get into a parser/interpreter, you need to design 
> your language (or you don't have anything to parse). If you haven't done 
> a parser before, then perhaps you could start (as a learning experience) 
> with a parser for an existing language.

Yes, just to clarify, I do HAVE a language very much well defined by now, I've been developing it on-and-off for more than 3 years, reading a lot and thinking about concepts and problems in programmning languages already existent, like those in Java, C++, Python, Objective-C, D, Lisp/Scheme, Prolog (not much relevant for my present designs, but I knew Prolog from long ago... the pattern-matching is interesting though), took a brief (and still incipent) look at Haskell and Ruby and so forth...

My language is very much like a C/C++ somewhat "modernized" and cleaned-up of a lot of "legacy" issues and fuss that I dislike a lot, also safe (arrays with a size and subscript checking, and a somewhat "clever" way to automatically/transparently dispense with the checking when statically it can be known to be safe, etc.), but I digress...

There are still one or two grey areas in my design, eg. I want to incorporate ASPECTS as similar to a object/class definition, say:

aspect logging(int size=15)  /*this declares, and is a constructor as well*/
  { int log[], current, max }  log = int[..max=size], current =0
end;
/* { ... declares the instance data...} followed by the constructor init.
   int[..size] allocates an array of specified size and sets to log
*/
logging.pointcut *d= x : write('data ', d, 'receives value ', x, '\n')
                         if (current < max) log[current++] = x  
end;
/* I'm still muddled on the specification of those cross-cuts, I need problems and concrete cases for it to solve.... :/

The thing is, I'm reaching the point that I NEED to start implementing it to sort out in a working version, not just in "theory" (which is what I've been doing till now)...

> For these two, refer to my first comment. Getting the language "right" 
> is more important than getting the compiler "efficient", especially at 
> the start. Yes, it is good to have an idea about what things make a 
> language hard to parse, but these tend to be basics, and not dependent 
> on the latest ideas of hash-tables etc.

What I think I'd need first is a library of hash-table manipulation and look up for implementing (in C; as another poster pointed-out, in C++ one'd use the STL hashtables, linkedlists, etc) for implementing the table of identifiers (global and local) that the parser will encounter at each source line and they'd need to be recorded along with all information on it (if it's an object type, all info on its traits, instances, fields, members, etc.)

As for things that'd make it hard to parse, no, I think I don't have syntax or elaborate semantics that'd be hard to parse (it will have operator overloading and new operators creation, though...;)

Moreover, I'm leaning on loosing up on the forward referencing restriction (like Java) of (eg.) C/C++ that make them require "prototyping" when referring before defining (perharps they aren't anymore?.. I'm still to catch up with C++11...) and have some sort of table of "referred but deferred, still undefined" identifiers and a backwards completion process when they eventually ARE defined (instead of a double-pass like Java).

> 
>  > - threading (I know the basic Unix's fork() call for creating new
>  > processes) but that doesn't count, does it?)
> 
> Threads aren't hard to create if the OS supplies the basic api (for *nix 
> look at the pthread library). Threads DO create a number of issues that 
> need to be solved, and it can be difficult to get and prove that a 
> program is 100% correct.

That's reassuring, so threads is something then that I don't need to worry for now, if there are library-functions provided by the different platforms, (and I can access them as C function-calls?).

Yes, about the issues... Well, I was going to start writing everything I'm thinking about it, but it's such a complex and overlong topic, that I'll leave for a future (soon) topic on its own: about problems and solutions.

(But for now, I'd have a qualifier, like C's const and restrict, 'locked', that'd be much like Java's synchronized, but would serve for data as well, not only routines (in Java, only methods in its JVM model).
To avoid deadlocks, my (incipient) idea (nothing new, actually...) was that their monitors or locks, or whatever internally 'locked' would translate to, would have a decrement counter, so that if a thread gets the 'floor' (err, gets active) but it can't do anything because it's waiting a locked routine/data ('locked' by another thread), then it'd decrement this counter: if it reaches 0 from a suitably defined quantity, it means it's doing nothing for a long time, and then probably other threads pending or holding on this lock are also doing nothing for a long time (they'd also be decrementing theirs). Hopefully, it'd be all because of circular locking dependencies, then when reaching 0 they'd all ignore the lock and move on... Yes, this is very mucg an ugly pickle that shall generate long 'threads' here (sorry...), but yeah, I know I still have to read and learn a lot about it.

> Different platforms can have differing object file formats. There are a 
> few standard ones, but depending on how universal you want to be, you 
> can run into a lot of them. You then have the issue of generating 
> machine code for a number of different machines architecture.
> 
> One common method when first developing a language is to compile to some 
> simpler language, C has been one common target. Once you have your 
> language worked out, and the front end parsing it right, you can then 
> start working on back ends to generate the output for the systems you 
> want to target.
> >

Yes, well, I'll probably first have a 'symbolic', working interpreter in C, as a case-test and proof-of-concept of sorts, then later worry with compilation or try to see if I can generate C code...
I just want to have something that "works" before presenting the whole thing for evaluation of everyone...

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

#60268

On 04/17/2015 04:33 PM, Emiliano Gomes Padilha wrote:
...
> That's reassuring, so threads is something then that I don't need to
> worry for now, if there are library-functions provided by the different
> platforms, (and I can access them as C function-calls?).

There are library functions available to implement threading on many
different platforms (but not all), and providing access to those
functions through a C interface is a very common thing. However, those
functions have different names on different platforms, and behave
differently on different platforms. Concepts that are meaningful for one
implementation of threading can be completely meaningless on another.
POSIX provides a pthreads library that you can use on any POSIX
platform. Windows provides something that I'm not familiar with that
will work on Windows platforms. There's many others that are less widely
supported.

C2011 adding threading functions for the first time, which are designed
so they can be implemented as thin wrappers for either the POSIX or
Windows functions. They can probably be implemented as thin wrappers
over other threading libraries, but I think that less effort was
expended to make sure of that. However, C2011 threads are not
necessarily available on all platforms. Also, they provide a
least-common-denominator implementation of threads - platform specific
threading functions often provide useful features that have no
equivalent in C2011 threads.

The answer, therefore, is that you can use a single interface to
implement threading on all platforms that are of interest to you - but
only if you've carefully chose which platforms you're interested in, to
make that possible.

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

#60196

On Thu, 16 Apr 2015 13:26:25 -0700 (PDT), Emiliano Gomes Padilha
<egpadilha@gmail.com> wrote:

>Hi,
>I'm designing a new programming language on the vein of C/C++ (I know, I know, "why are you doing that?, It's worthless, don't do that, Yet another goof, etc..").
>Nevertheless, please let me pursue my "vain" effort, and anyway because I don't have experience in designing & programming parsers/interpreters/compilers (other than the long-ago class I had on Compilers in my Computer Science graduation -- I have a Msc and Phd but it's in Artificial Intelligence & Natural Language/Cognitive Science, so... very different fields of study!),
>
>therefore I'm looking for any pointers anyone around might have on where do I start. I know I'll program a parser/interpreter and later possibly compilers (hopefully for different platforms) in C (NOT C++, I know both but I prefer to go with the basics in this "low-level" project).


Eh.  C++ is, IMO, a rather better language for something like a
compiler.  It's a large enough project, and the added abstractions can
be very useful.  Although if implementations constraints didn't
usually forbid it, I'd prefer something like Haskell.  A compiler is
mainly a lot of data structure manipulation, go for a language good at
that.


>My language is going to be object-oriented, threaded, functional, statically & dynamically imperative as well (yes, I KNOW what all these mean, I'm versed in programming language concepts/design, I just don't know much on the INTERNALS), so if anyone can point me to information on:
>
>- modern parsing/optimization techniques (info and/or codes)


Really, you're getting way ahead of yourself here.  Get to the point
where you're generating working code, than then worry about
optimization.  If you've never done this before (and clearly you
haven't), you're way out of your depth trying to design too much of
the back end now.

For the parser, start with one of the parser generators.  They're all
ugly, but you can replace it later.


>- look-up tables, hashing info and techniques to get the best/efficient hashing on tables of identifiers of various types (functions, basic types, objects, global/local, etc.)


Again, wait until you find out what matters.  Do yourself a favor and
implement these "containers" with well defined interfaces, and when
you find out one is too small, you can just go in later and do
something fancier.


>- threading (I know the basic Unix's fork() call for creating new processes) but that doesn't count, does it?)


Seriously, this is an immensely difficult subject.  If you've not done
any work here, you're basically doomed to failure trying to design a
language that can cleanly handle threading issues.  The pitfalls and
race conditions are many.  But start by understanding one of the
common threading models, pthreads is fine.  Then spend some time
reading about all the problems people have using it.  Then look at
some of the languages that have tried to incorporate threading in a
"simple" manner (like Java), and study how even highly experienced
people have messed it up.


>- the formats and linking process of C/C++ object files/symbol tables (are they the same on different platforms?? Say, is the object/symbol table generated by 'cc/gcc' on Linux, Unix'es, Windows's, MacOXs the same apart from the differing machine codes?)


Object module formats are different on every platform.  They are also
tedious and not very interesting.  *Don't* generate them directly.  If
you're compiling to machine code, output assembler, and then assemble
it.  At least for a given processor family, assembler syntax is going
to be a lot easier to alter between platforms than object file output.
If at some point in the future you want to ditch the assembler, just
paste on your own.

Or avoid all that, and start by emitting C or C++ code from your
compiler.  It worked well enough for C++ for a long time (until
exceptions got added to the mix).  That not only removes you from
dealing with the ISA, it also eliminates most of the platform
dependencies (assuming you emit fairly portable C or C++ code). Again,
you can revisit the back end later.

Get your language working first, while taking advantage of as many
tools as you can.  That's an immense task all by itself.  You can
always optimize things later.

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

#60209

On 17/04/15 06:02, Robert Wessel wrote:
> On Thu, 16 Apr 2015 13:26:25 -0700 (PDT), Emiliano Gomes Padilha 
> <egpadilha@gmail.com> wrote:
> 
>> Hi, I'm designing a new programming language on the vein of C/C++
>> (I know, I know, "why are you doing that?, It's worthless, don't do
>> that, Yet another goof, etc.."). Nevertheless, please let me pursue
>> my "vain" effort, and anyway because I don't have experience in
>> designing & programming parsers/interpreters/compilers (other than
>> the long-ago class I had on Compilers in my Computer Science
>> graduation -- I have a Msc and Phd but it's in Artificial
>> Intelligence & Natural Language/Cognitive Science, so... very
>> different fields of study!),
>> 
>> therefore I'm looking for any pointers anyone around might have on
>> where do I start. I know I'll program a parser/interpreter and
>> later possibly compilers (hopefully for different platforms) in C
>> (NOT C++, I know both but I prefer to go with the basics in this
>> "low-level" project).
> 
> 
> Eh.  C++ is, IMO, a rather better language for something like a 
> compiler.  It's a large enough project, and the added abstractions
> can be very useful.  Although if implementations constraints didn't 
> usually forbid it, I'd prefer something like Haskell.  A compiler is 
> mainly a lot of data structure manipulation, go for a language good
> at that.
> 

I would go for a higher level language - Python is the obvious choice
for implementing a parser/compiler for a new language.  It already has
libraries for parsing and compiling that are very efficient and
(relatively) easy to use - most of the Python bytecode compiler itself
is there.  And while C++ makes it vastly easier to work with lists,
hash-tables, trees, etc., than C, Python makes it vastly easier again.

If the final result is supposed to be natively compiled, using the
Python front-end to pass on the results down to llvm for middle-end
optimisation and code generation.

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

#60335

Em sexta-feira, 17 de abril de 2015 05:55:29 UTC-3, David Brown  escreveu:
> On 17/04/15 06:02, Robert Wessel wrote:
>...
> > Eh.  C++ is, IMO, a rather better language for something like a 
> > compiler.  It's a large enough project, and the added abstractions
> > can be very useful.  Although if implementations constraints didn't 
> > usually forbid it, I'd prefer something like Haskell.  A compiler is 
> > mainly a lot of data structure manipulation, go for a language good
> > at that.
> > 
> 
> I would go for a higher level language - Python is the obvious choice
> for implementing a parser/compiler for a new language.  It already has
> libraries for parsing and compiling that are very efficient and
> (relatively) easy to use - most of the Python bytecode compiler itself
> is there.  And while C++ makes it vastly easier to work with lists,
> hash-tables, trees, etc., than C, Python makes it vastly easier again.
> 
> If the final result is supposed to be natively compiled, using the
> Python front-end to pass on the results down to llvm for middle-end
> optimisation and code generation.

Eh, that's interesting. I've looked at Python only in terms of what it provides of resources and how it does things at the language-level. Though I grant that there are useful concepts and ideas there, I don't quite like the way some things are done, and frankly the syntax is also not my favourite, C-style is still the most practical IMO (albeit the idea of using indentation, not as the main method of structuring code, but as an auxiliary, I incorporated in my language).
However, I didn't know its compiled code (bytecode) would be fast. I1ve heard from others that the interpretation certainly isn't. But it's just my ignorance of many things there apart from the high-level language concepts and syntax; although I remember browsing Python's library and not finding anything there much exceptional; I certainly don't remember utilities for parsing and compiling...
Ah, ok, they aren't in the STANDARD library you seemed to imply, right?

Emiliano.

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

#60343

On 18/04/15 20:48, Emiliano Gomes Padilha wrote:
> Em sexta-feira, 17 de abril de 2015 05:55:29 UTC-3, David Brown
> escreveu:
>> On 17/04/15 06:02, Robert Wessel wrote: ...
>>> Eh.  C++ is, IMO, a rather better language for something like a
>>> compiler.  It's a large enough project, and the added
>>> abstractions can be very useful.  Although if implementations
>>> constraints didn't usually forbid it, I'd prefer something like
>>> Haskell.  A compiler is mainly a lot of data structure
>>> manipulation, go for a language good at that.
>>>
>>
>> I would go for a higher level language - Python is the obvious
>> choice for implementing a parser/compiler for a new language.  It
>> already has libraries for parsing and compiling that are very
>> efficient and (relatively) easy to use - most of the Python
>> bytecode compiler itself is there.  And while C++ makes it vastly
>> easier to work with lists, hash-tables, trees, etc., than C, Python
>> makes it vastly easier again.
>>
>> If the final result is supposed to be natively compiled, using the
>> Python front-end to pass on the results down to llvm for
>> middle-end optimisation and code generation.
>
> Eh, that's interesting. I've looked at Python only in terms of what
> it provides of resources and how it does things at the
> language-level. Though I grant that there are useful concepts and
> ideas there, I don't quite like the way some things are done, and
> frankly the syntax is also not my favourite, C-style is still the
> most practical IMO (albeit the idea of using indentation, not as the
> main method of structuring code, but as an auxiliary, I incorporated
> in my language).

Well, Python is not to everyone's taste - and like every language I know 
of, it has its disadvantages.  But it has an enormous library that is 
well-tested and well-documented, and includes a set of modules for 
parsing programming languages.  Several of the modules are geared 
specifically at parsing Python, but some are more generally useful for 
other languages.  I haven't used these myself, but have heard of others 
using them.  So I can't say that they will definitely help you, but I 
believe they are worth a look:

<https://docs.python.org/3/library/language.html>

Python also has easy high-level string handling, pattern matching, and 
support for key data structures such as hash tables and lists.

> However, I didn't know its compiled code (bytecode)
> would be fast. I1ve heard from others that the interpretation
> certainly isn't. But it's just my ignorance of many things there
> apart from the high-level language concepts and syntax; although I
> remember browsing Python's library and not finding anything there
> much exceptional; I certainly don't remember utilities for parsing
> and compiling... Ah, ok, they aren't in the STANDARD library you
> seemed to imply, right?
>

Compilation to Python bytecode is fast - it is the execution of that 
bytecode in the virtual machine that can be quite slow.  Much of that is 
due to the flexibility of Python - because you can do all sorts of 
messing around such as overriding methods of any object, the interpreter 
has to keep looking things up in symbol tables and can't optimise in the 
way a more static language would allow.  However, modern development in 
Python includes pypy, which sacrifices a little of this flexibility but 
allows just-in-time compilation with llvm to run Python code much faster.

But in general, the emphasis is on fast development rather than fast 
run-time.

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

#60390

On Sat, 2015-04-18, David Brown wrote:
> On 18/04/15 20:48, Emiliano Gomes Padilha wrote:
>> Em sexta-feira, 17 de abril de 2015 05:55:29 UTC-3, David Brown
>> escreveu:
>>> On 17/04/15 06:02, Robert Wessel wrote: ...
>>>> Eh.  C++ is, IMO, a rather better language for something like a
>>>> compiler.  It's a large enough project, and the added
>>>> abstractions can be very useful.  Although if implementations
>>>> constraints didn't usually forbid it, I'd prefer something like
>>>> Haskell.  A compiler is mainly a lot of data structure
>>>> manipulation, go for a language good at that.
>>>>
>>>
>>> I would go for a higher level language - Python is the obvious
>>> choice for implementing a parser/compiler for a new language.  It
>>> already has libraries for parsing and compiling that are very
>>> efficient and (relatively) easy to use - most of the Python
>>> bytecode compiler itself is there.  And while C++ makes it vastly
>>> easier to work with lists, hash-tables, trees, etc., than C, Python
>>> makes it vastly easier again.
...
>> Eh, that's interesting. I've looked at Python only in terms of what
>> it provides of resources and how it does things at the
>> language-level. Though I grant that there are useful concepts and
>> ideas there, I don't quite like the way some things are done, and
>> frankly the syntax is also not my favourite, C-style is still the
...

> Well, Python is not to everyone's taste - and like every language I know 
> of, it has its disadvantages.

The lack of static type checking would be thing I'd fear the most, if
I was using it to implement a compiler.  YMMV.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#60391

On 19/04/2015 12:39, Jorgen Grahn wrote:
> On Sat, 2015-04-18, David Brown wrote:

>> Well, Python is not to everyone's taste - and like every language I know
>> of, it has its disadvantages.
>
> The lack of static type checking would be thing I'd fear the most, if
> I was using it to implement a compiler.  YMMV.

Why? A compiler can do static type checking on its input whether or not 
the language it's implemented in has static type checking.

-- 
Bartc

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

#60400

On Sun, 2015-04-19, Bartc wrote:
> On 19/04/2015 12:39, Jorgen Grahn wrote:
>> On Sat, 2015-04-18, David Brown wrote:
>
>>> Well, Python is not to everyone's taste - and like every language I know
>>> of, it has its disadvantages.
>>
>> The lack of static type checking would be thing I'd fear the most, if
>> I was using it to implement a compiler.  YMMV.
>
> Why? A compiler can do static type checking on its input whether or not 
> the language it's implemented in has static type checking.

Yes, of course it can.

My concern is, I expect the source code of a compiler to be complex
and to be implemented using a lot of user-defined types.  Not having
static checking on them would make me nervous.

But once again -- YMMV.  I was raised on languages with static type
checking, and believe it's the better choice for anything that's
complex and still needs to work properly.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#60465

On 19/04/15 13:39, Jorgen Grahn wrote:
> On Sat, 2015-04-18, David Brown wrote:
>> On 18/04/15 20:48, Emiliano Gomes Padilha wrote:
>>> Em sexta-feira, 17 de abril de 2015 05:55:29 UTC-3, David Brown
>>> escreveu:
>>>> On 17/04/15 06:02, Robert Wessel wrote: ...
>>>>> Eh.  C++ is, IMO, a rather better language for something like a
>>>>> compiler.  It's a large enough project, and the added
>>>>> abstractions can be very useful.  Although if implementations
>>>>> constraints didn't usually forbid it, I'd prefer something like
>>>>> Haskell.  A compiler is mainly a lot of data structure
>>>>> manipulation, go for a language good at that.
>>>>>
>>>>
>>>> I would go for a higher level language - Python is the obvious
>>>> choice for implementing a parser/compiler for a new language.  It
>>>> already has libraries for parsing and compiling that are very
>>>> efficient and (relatively) easy to use - most of the Python
>>>> bytecode compiler itself is there.  And while C++ makes it vastly
>>>> easier to work with lists, hash-tables, trees, etc., than C, Python
>>>> makes it vastly easier again.
> ...
>>> Eh, that's interesting. I've looked at Python only in terms of what
>>> it provides of resources and how it does things at the
>>> language-level. Though I grant that there are useful concepts and
>>> ideas there, I don't quite like the way some things are done, and
>>> frankly the syntax is also not my favourite, C-style is still the
> ...
>
>> Well, Python is not to everyone's taste - and like every language I know
>> of, it has its disadvantages.
>
> The lack of static type checking would be thing I'd fear the most, if
> I was using it to implement a compiler.  YMMV.
>

The lack of static type checking on the Python code does not influence 
the checking (or lack thereof) of code in the language you are compiling.

(I too find lack of static type checking to be the biggest disadvantage 
of Python.  You can do some static checking with pychecker or pylint 
utilities.)

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

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

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

csiph-web