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

Groups > comp.lang.forth > #56536 > unrolled thread

LLVM and Forth

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

Contents

  LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
    Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
      Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
        Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
    Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
      Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
        Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
          Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
            Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
            Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
              Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
                Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
                  Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
                    Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
                      Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
                    Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
                      Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
                      Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
                      Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
              Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
            Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
              Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
              Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
                Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
                  Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
                    Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
                      Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
                      Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
                      Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
                        Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
                        Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
                        Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
                          Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
                            Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
                              Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
                            Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
                              Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
                          Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
                            Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
                              Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
                                Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
                                Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
                                  Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
                                Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
                                  Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
                                  Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
                                    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
                                      Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
                                      Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
                                      Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
                                  Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
                          Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
                            Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
                Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
                Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
              Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
                Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
                  Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
                    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
                  Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
                Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
                  Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
                  Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
                    Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
                      Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
                        Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
                          Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
                            Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
                              Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
                              Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
                            Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
                              Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
                                Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
                                  Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
                                    Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
                                      Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
                                        Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
                                          Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
                                Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
                                Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
                                  Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
                                    Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
                                  Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
                                    Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
                                      Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
                                    Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
                                      Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
                          Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
                            Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
                          Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
                            Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
                              Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
                                Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
                        Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
                          Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
                            Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
                      Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
                      Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
                        Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
                          Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
                          Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
                            Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
                              Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
                            Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
                              Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
                                Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
                                  Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
                                    Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
                                      Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
                                        Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
                                  Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
            Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
    Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
      Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
        Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
          Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
            Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
              Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
                Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
        Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
          Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
            Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
          Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
      Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
        Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
    Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
      Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#56536 — LLVM and Forth

Question: 

Are there any existing Forth systems built from the LLVM tools (link below)? What advantages might LLVM provide for a low-level language such as Forth?

Krishna

http://llvm.org/

[toc] | [next] | [standalone]

#56539

krishna.myneni@ccreweb.org writes:
>Question: 
>
>Are there any existing Forth systems built from the LLVM tools (link below)?

AFAIK no.

> What advantages might LLVM provide for a low-level language such as Forth?

None that justify the disadvantages.

The advantages are that there LLVM has at least two targets (some ARM
architecture and some Intel architecture).

The disadvantages are:

  - It compiles slowly.

  - It's oriented towards nasal demon C, the dialect of C that's
    currently popular with C compiler maintainers.  As a consequence,

    - You have to divide your program into (the LLVM representation
      of) C functions, that call each other with C calling
      conventions.  There has been one attempt to use a different
      calling convention, but that's apparently very difficult.

    - If you lie down with dogs, you get up with fleas.  I expect that
      your compiler can easily become possessed by nasal demons (i.e.,
      compile programs differently than what you and the programmer
      intended).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56549

On Saturday, April 1, 2017 at 10:12:08 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >Question: 
> >
> >Are there any existing Forth systems built from the LLVM tools (link below)?
> 
> AFAIK no.
> 
> > What advantages might LLVM provide for a low-level language such as Forth?
> 
> None that justify the disadvantages.
> 

I'm always wary of tying programs to complex libraries, unless the benefits are warranted. In this case, I didn't know much about the complexity of the libraries, the LLVM language, and the benefits, other than being able to target x86, PowerPC, and ARM all at the same time, from the same source code.

> The advantages are that there LLVM has at least two targets (some ARM
> architecture and some Intel architecture).
>

+ PowerPC (?)
 
> The disadvantages are:
> 
>   - It compiles slowly.
> 

That's not necessarily a show stopper.

>   - It's oriented towards nasal demon C, the dialect of C that's
>     currently popular with C compiler maintainers.  As a consequence,
> 
>     - You have to divide your program into (the LLVM representation
>       of) C functions, that call each other with C calling
>       conventions.  There has been one attempt to use a different
>       calling convention, but that's apparently very difficult.
> 
>     - If you lie down with dogs, you get up with fleas.  I expect that
>       your compiler can easily become possessed by nasal demons (i.e.,
>       compile programs differently than what you and the programmer
>       intended).
> 

Hmm... your assessment seems pretty harsh. However, the mutable interpretation of previously solid C code in recent C compilers, as we discussed previously here in c.l.f., is a prevalent problem. I would be very concerned in using the LLVM tools if it isolated me from mixing machine-specific assembly code into the compiler.

Krishna

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

#56591

krishna.myneni@ccreweb.org writes:
>On Saturday, April 1, 2017 at 10:12:08 AM UTC-5, Anton Ertl wrote:
[...]
>In this case, I didn't know much about the complexity of th=
>e libraries, the LLVM language, and the benefits, other than being able to =
>target x86, PowerPC, and ARM all at the same time, from the same source cod=
>e.

If that's what's of interest to you, you could also take a look at GNU
Lightning.

>> The advantages are that there LLVM has at least two targets (some ARM
>> architecture and some Intel architecture).
>>
>
>+ PowerPC (?)

Maybe.  Apple removed OS support for PowerPC in 2009, so they probably
no longer use the PowerPC back end.  So while the PowerPC port may
still be there, it may suffer from bit rot.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56540

On 4/1/2017 9:36 AM, krishna.myneni@ccreweb.org wrote:
> Question:
>
> Are there any existing Forth systems built from the LLVM tools (link below)? What advantages might LLVM provide for a low-level language such as Forth?
>
> Krishna
>
> http://llvm.org/

"Despite its name, LLVM has little to do with traditional virtual 
machines"...  "The name "LLVM" itself is not an acronym; it is the full 
name of the project."

So if the name is just some unpronounceable letters, why would that 
imply anything about virtual machines???

-- 

Rick C

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

#56550

On Saturday, April 1, 2017 at 10:21:41 AM UTC-5, rickman wrote:
> On 4/1/2017 9:36 AM, krishna.myneni@ccreweb.org wrote:
> > Question:
> >
> > Are there any existing Forth systems built from the LLVM tools (link below)? What advantages might LLVM provide for a low-level language such as Forth?
> >
> > Krishna
> >
> > http://llvm.org/
> 
> "Despite its name, LLVM has little to do with traditional virtual 
> machines"...  "The name "LLVM" itself is not an acronym; it is the full 
> name of the project."
> 
> So if the name is just some unpronounceable letters, why would that 
> imply anything about virtual machines???
> 

Supposedly Java virtual machines have been developed with LLVM.

Krishna

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

#56579

krishna.myneni@ccreweb.org wrote:
> 
> Supposedly Java virtual machines have been developed with LLVM.

It is very difficult, partly for the reasons described: LLVM uses C
semantics for its intermedieate language, so if your language is along
way from C this can be problematic.  Optimizing without specific
language semantics is somewhere between hard and impossible.

Andrew.

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

#56586

On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote:
> krishna.myneni@ccreweb.org wrote:
> > 
> > Supposedly Java virtual machines have been developed with LLVM.
> 
> It is very difficult, partly for the reasons described: LLVM uses C
> semantics for its intermedieate language, so if your language is along
> way from C this can be problematic.  Optimizing without specific
> language semantics is somewhere between hard and impossible.
> 

The fundamental question appears to be independent of LLVM:

If one were to write a Forth to C translator, how likely is it that the translator would result in C code which is considered undefined in the new C standard, i.e. how problematic would "nasal demons" be in the translated code?

I have one incident of manually implementing a Forth word in C that resulted in undefined code with the result that a dictionary word broke without warning at some point. Anton may have had a larger share of these types of problems. Who would have thought that we would reach a stage where Fortran became a saner language than C?! The scientific community, at least, was proven correct in hanging on to Fortran.

Krishna

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

#56588

krishna.myneni@ccreweb.org writes:
>On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote:
>> Optimizing without specific
>> language semantics is somewhere between hard and impossible.

Not in the least.  On the contrary, it's harder to "optimize" using
nasal demon semantics, and that's why such "optimizations" are a
relatively recent development.

You can translate the source code to machine code according to the
semantics of the programming language, and then optimize the machine
code.  In practice, they used to translate to an intermediate
representation (IR) with machine-level operations, then optimize that,
and then generate code from that.

The newer developments are that they added stuff such as "undefined",
assertions about, e.g., the possible values of things (derived from
nasal demon C semantics), and operations with language-specific nasal
demons to the IR.  One could try to avoid all these cliffs, and just
use the machine-level operations (if they are still there), but I
would not bet that every optimization pass (there are several hundred
in LLVM and GCC) actually observes the machine-level semantics rather
than taking liberties based on C semantics.

>The fundamental question appears to be independent of LLVM:
>
>If one were to write a Forth to C translator, how likely is it that the tra=
>nslator would result in C code which is considered undefined in the new C s=
>tandard, i.e. how problematic would "nasal demons" be in the translated cod=
>e?

For a straightforward translation, the likelyhood of undefined
behaviour from many Forth programs is 100%; maybe you are lucky, and
the C compiler still generates the code you intended, maybe not; in
the next compiler version it may be different.

You could go for a more roundabout translation, and with lots of
perseverance and some luck get a translation without undefined
behaviour, but it would be slow and interfacing with the rest of the
world would probably be a problem.

But that's a nasal-demon-C-specific problem.  The LLVM people could
have chosen to just have a machine-level IR without any nasal demon
nonsense, and then LLVM would not have had this problem.  So the
problem is not really independent of LLVM.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56647

Am Sonntag, 2. April 2017 15:35:26 UTC+2 schrieb krishna...@ccreweb.org:
> On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote:
> > krishna.myneni@ccreweb.org wrote:
> > > 
> > > Supposedly Java virtual machines have been developed with LLVM.
> > 
> > It is very difficult, partly for the reasons described: LLVM uses C
> > semantics for its intermedieate language, so if your language is along
> > way from C this can be problematic.  Optimizing without specific
> > language semantics is somewhere between hard and impossible.
> > 
> 
> The fundamental question appears to be independent of LLVM:
> 
> If one were to write a Forth to C translator, how likely is it that the translator would result in C code which is considered undefined in the new C standard, i.e. how problematic would "nasal demons" be in the translated code?
> 
> I have one incident of manually implementing a Forth word in C that resulted in undefined code with the result that a dictionary word broke without warning at some point. Anton may have had a larger share of these types of problems. Who would have thought that we would reach a stage where Fortran became a saner language than C?! The scientific community, at least, was proven correct in hanging on to Fortran.
> 
> Krishna

I am using a Forth to C translator, where only a rather small subset of (pseudo) Forth words is translated to create an application kernel, including interactivity if the application requires it. The rest is built on top of the kernel without the translator. One proof-of-concept application is a full Forth system that passes the Forth200x test suite successfully including all wordsets.

So there is no undefined code. I have never encountered C Compiler problems because kernels are small and the resulting C code is straightforward and doesn't use any esoteric constructs. KISS is always a good pronciple.

I do not understand why Forth-to-C cross-compilers are so poorly regarded here.

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

#56658

On Monday, April 3, 2017 at 3:10:00 AM UTC-5, minf...@arcor.de wrote:
> Am Sonntag, 2. April 2017 15:35:26 UTC+2 schrieb krishna...@ccreweb.org:
> 
> I am using a Forth to C translator, where only a rather small subset of (pseudo) Forth words is translated to create an application kernel, including interactivity if the application requires it. The rest is built on top of the kernel without the translator. One proof-of-concept application is a full Forth system that passes the Forth200x test suite successfully including all wordsets.
> 
> So there is no undefined code. I have never encountered C Compiler problems because kernels are small and the resulting C code is straightforward and doesn't use any esoteric constructs. KISS is always a good pronciple.
> 
> I do not understand why Forth-to-C cross-compilers are so poorly regarded here.

A couple of us have been burned by changes to the C compiler (GCC) which affected (broke) the Forth systems we maintained. These compiler changes did not output warnings, unless one specified a high enough warning level, and, therefore, I learned of the side effects much later. This was a case of transforming an unambiguous C statement into undefined behavior in the new C standard, for the sake of optimization. The new C standard apparently has plenty of such undefined behaviors, sacrificing language safety for the sake of compiler optimization. From the LLVM project blog:

"Undefined behavior exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language. In contrast, languages like Java (and many other 'safe' languages) have eschewed undefined behavior because they want safe and reproducible behavior across implementations, and willing to sacrifice performance to get it. While neither is "the right goal to aim for," if you're a C programmer you really should understand what undefined behavior is."

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Personally, I think the extra CPU power of modern processors should be weighted much more towards language safety rather than maximal efficiency. As people get burned, the glaring deficiencies of the insane drive to efficiency are driving some of us away from C-like languages.

Krishna

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

#56661

krishna.myneni@ccreweb.org writes:
>On Monday, April 3, 2017 at 3:10:00 AM UTC-5, minf...@arcor.de wrote:
>> So there is no undefined code. I have never encountered C Compiler proble=
>ms because kernels are small and the resulting C code is straightforward an=
>d doesn't use any esoteric constructs. KISS is always a good pronciple.

It does not help against nasal demons.  You can get them in just a few
characters, and with code that most people would see as
straighforward.  E.g., try to write rotl32(int x, unsigned n) or
memmove() in C.

>The new C standard apparently has p=
>lenty of such undefined behaviors, sacrificing language safety for the sake=
> of compiler optimization. From the LLVM project blog:
>
>"Undefined behavior exists in C-based languages because the designers of C =
>wanted it to be an extremely efficient low-level programming language. In c=
>ontrast, languages like Java (and many other 'safe' languages) have eschewe=
>d undefined behavior because they want safe and reproducible behavior acros=
>s implementations, and willing to sacrifice performance to get it. While ne=
>ither is "the right goal to aim for," if you're a C programmer you really s=
>hould understand what undefined behavior is."
>
>http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Yes, the nasal demon fans claim that they invite nasal demons for
performance reasons, but they rarely, if ever provide empirical
evidence of the performance effects.

That's because the performance effects of nasal demon "optimizations"
are so small that most production programmers would boycott the newer
C compilers with more nasal demons if they knew it.  However, Wang et
al. actually measured the performance effect: Even on the SPECint
benchmarks, which are in a privileged position (GCC and LLVM
maintainers optimize for them and don't dare miscompile them, and
therefore they don't have to be "sanitized", which could reduce their
performance), the speedup is <2%.

>Personally, I think the extra CPU power of modern processors should be weig=
>hted much more towards language safety rather than maximal efficiency.

This is a false dichotomy.  Nasal demons hurt efficiency: If you want
to avoid undefined behaviour, you avoid many efficient idioms; in
addition, you have to invest lots of time in "sanitizing" your
program, and you miss that time when it comes to making your program
faster; plus, every change to your program (such as implementing an
optimization idea) incurs the danger of introducing undefined
behaviour into your carefully sanitized program, so better not go
there.

This is actually not specific to newer C standards.  Older C standards
also had lots of undefined behaviour.  The problem is actually in the
newer C compilers and their maintainers, who think it is a good idea
to put nasal demons in their compilers.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56663

Am Montag, 3. April 2017 16:27:46 UTC+2 schrieb Anton Ertl:
> krishna.myneni@ccreweb.org writes:
> >On Monday, April 3, 2017 at 3:10:00 AM UTC-5, minf...@arcor.de wrote:
> >> So there is no undefined code. I have never encountered C Compiler proble=
> >ms because kernels are small and the resulting C code is straightforward an=
> >d doesn't use any esoteric constructs. KISS is always a good pronciple.
> 
> It does not help against nasal demons.  You can get them in just a few
> characters, and with code that most people would see as
> straighforward.  E.g., try to write rotl32(int x, unsigned n) or
> memmove() in C.
> 

I am interested in bug-free results, not so much in perfect tools. Primarily I have to assert my _applications_ thoroughly.

Thereby hoping that wrong binaries caused by compiler bugs or poor language specifications are detected as well. In the desktop world one can chose from many compiler vendors, but in the embedded or controller domain there is often just one = the compiler that you have to live with. 

BTW is there any "nasal demon" free programming language specification at all??
How do Ada, Haskell, Misra-C, FORTRAN fare here?

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

#56670

minforth@arcor.de writes:
>BTW is there any "nasal demon" free programming language specification at a=
>ll??

Sure; many higher-level languages define everything, i.e., every
operation produces either a result or a defined error condition.  Java
even tries to guarantee the same result, and uses the slogan "Write
once, run anywhere" for that.

Machine language also defines everything.

For other low-level languages, Forth and probably many others do not
have the time-traveling twist that C has and that plays a significant
role in conjuring up nasal demons.  And most don't have compilers that
do such nonsense.

>How do Ada, Haskell, Misra-C, FORTRAN fare here?

Fortran is notorious for undefined behaviour; however, nasal demon C
may have overtaken it in the nasal demon department.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#56671

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> minforth@arcor.de writes:
>>BTW is there any "nasal demon" free programming language specification at a=
>>ll??
> 
> Sure; many higher-level languages define everything, i.e., every
> operation produces either a result or a defined error condition.  Java
> even tries to guarantee the same result, and uses the slogan "Write
> once, run anywhere" for that.
> 
> Machine language also defines everything.

Not quite: IIRC you've said that before, and I thought I corrected you
when you said it before.  ARM says for code which is modified and then
executed without proper synchronization:

  "Concurrent modification and execution of instructions can lead to
  the resulting instruction performing any behavior that can be
  achieved by executing any sequence of instructions that can be
  executed from the same Exception level, except where the instruction
  before modification and the instruction after modification is a B,
  BL, NOP, BRK, SVC, HVC, or SMC instruction."

Granted, this isn't quite nasal daemons, but "any sequence of
instructions" is pretty close.

Andrew.

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

#56683

minforth@arcor.de writes:
> BTW is there any "nasal demon" free programming language specification
> at all??  How do Ada, Haskell, Misra-C, FORTRAN fare here?

Misra-C has the same issues as regular C.  Haskell might not have nasal
demons but its specification is somewhat loose.  Ada is extremely
solidly specified and I don't know of any UB in it.  One of the design
goals of Algol 60 was also to have no UB.  ML or something related to it
is completely formally specified.  Rust seems to go far compared with C
in avoiding UB but I don't know if UB is completely absent in it.

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

#56686

Am Dienstag, 4. April 2017 05:10:29 UTC+2 schrieb Paul Rubin:
> minforth@arcor.de writes:
> > BTW is there any "nasal demon" free programming language specification
> > at all??  How do Ada, Haskell, Misra-C, FORTRAN fare here?
> 
> Misra-C has the same issues as regular C.  Haskell might not have nasal
> demons but its specification is somewhat loose.  Ada is extremely
> solidly specified and I don't know of any UB in it.  One of the design
> goals of Algol 60 was also to have no UB.  ML or something related to it
> is completely formally specified.  Rust seems to go far compared with C
> in avoiding UB but I don't know if UB is completely absent in it.

Is having a formal specification equivalent to free of unspecified behaviour?

Altogether it seems somewhat academic. Otherwise all safety-critical system software would have to be programmed in certified languages. And I never heard of ML being used for that.   

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

#56706

In article <87zifw50m7.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>minforth@arcor.de writes:
>> BTW is there any "nasal demon" free programming language specification
>> at all??  How do Ada, Haskell, Misra-C, FORTRAN fare here?
>
>Misra-C has the same issues as regular C.  Haskell might not have nasal
>demons but its specification is somewhat loose.  Ada is extremely
>solidly specified and I don't know of any UB in it.  One of the design
>goals of Algol 60 was also to have no UB.  ML or something related to it
>is completely formally specified.  Rust seems to go far compared with C
>in avoiding UB but I don't know if UB is completely absent in it.

Also algol68 is completely formally specified using a van Wijngaarden
grammer. This went so far that a program with what in other languages
would lead to an undefined identifier, would be a ungrammatical
program. (The infamous two level grammar. I'm not aware of a
compiler that could take advantage of this.).

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#56762

On 2017-04-03 11:10 PM, Paul Rubin wrote:
> minforth@arcor.de writes:
>> BTW is there any "nasal demon" free programming language
>> specification at all??  How do Ada, Haskell, Misra-C, FORTRAN fare
>> here?
>
> Misra-C has the same issues as regular C.  Haskell might not have
> nasal demons but its specification is somewhat loose.  Ada is
> extremely solidly specified and I don't know of any UB in it.  One of
> the design goals of Algol 60 was also to have no UB.  ML or something
> related to it is completely formally specified.  Rust seems to go far
> compared with C in avoiding UB but I don't know if UB is completely
> absent in it.
>

Your point is well taken but Misra-C significantly reduces many of the C
language issues.

A second point is may automotive applications are written using
implementation rules that are a subset of Misra-C.

There are implementation process standards for most industries that
require reliable application implementation.

This is true for automotive, medical devices, and aviation. It is
possible to make applications reliable independent of the implementation
languages.

One of the simplest ways of making applications reliable is having an
application beta tested for a significant amount of time on a real
application following the last change before release.

Automotive engine controllers require two years data after the internal
release until the code is shipped.

w..

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

#56662

minforth@arcor.de writes:
>I am using a Forth to C translator, where only a rather small subset of (ps=
>eudo) Forth words is translated to create an application kernel, including =
>interactivity if the application requires it. The rest is built on top of t=
>he kernel without the translator. One proof-of-concept application is a ful=
>l Forth system that passes the Forth200x test suite successfully including =
>all wordsets.
>
>So there is no undefined code.

How do you know?  Just because the program works as intended does not
guarantee that there is no undefined behaviour.  The next version of
your C compiler could turn the undefined behaviour into nasal demons.

Gforth is chock full of undefined behaviour, yet it works as intended
with the compilers we tested.  Now and then newer compiler versions
miscompile Gforth, then we need to deal with that by disabling (if
possible) the "optimization" that caused this, or by changing the
source code of Gforth.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

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

csiph-web