Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: rhel 7 and kforth Date: Tue, 28 Apr 2015 17:14:52 -0700 Organization: A noiseless patient Spider Lines: 29 Message-ID: <87d22nvlhf.fsf@jester.gateway.pace.com> References: <2015Apr20.140504@mips.complang.tuwien.ac.at> <87sibtx8ob.fsf@jester.gateway.sonic.net> <2015Apr22.130001@mips.complang.tuwien.ac.at> <878udhmle2.fsf@jester.gateway.sonic.net> <2015Apr25.184119@mips.complang.tuwien.ac.at> <2015Apr26.165622@mips.complang.tuwien.ac.at> <6f87de3d-bf50-4d21-814b-e106b29cd299@googlegroups.com> <2015Apr27.110253@mips.complang.tuwien.ac.at> <5e7af70a-115a-4b7c-a8ae-7871a8fb6ded@googlegroups.com> <87h9rzvmqt.fsf@jester.gateway.pace.com> <5f64b74e-d874-4011-8978-c77c24d7070c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bda44be170c76b3ef6d23fecd204a8fa"; logging-data="26327"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wnGTqIiAOaYWoaRUxMVur" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:JH8EXohKSziO4bvktiqDGgl10cw= sha1:dyGLoEBLbchZjd5glORxJ7o2gw8= Xref: csiph.com comp.lang.forth:38704 krishna.myneni@ccreweb.org writes: > The rationalization of crazy compiler behavior is no longer > important. It's a question of its prevalence. I think optimizers will get even more aggressive rather than less. The only promising countermeasure is to define a dialect like Regehr's "friendly C" and get compilers to implement it. > I think many of us probably agree that the compiler has gone off the > rails, with its optimizations. I think the x+1>x optimization was "legitimate" in the sense that it wasn't based on inferring something from the assumption that some other part of the program didn't do a UB. The compiler is not off the rails. One can argue that the language (or anyway the ANSI standard) is off the rails, but the compiler is doing what the standard writers intended for it to do. > For my own Forth system, I won't be able to replace the C/C++ compiler > very quickly. You might try something like Frama-C to check for other such issues. > For the present, I'm starting to move as much of the functionality as > possible into assembler code. But, I expect I will still need a > high-level language to implement the top layer of the Forth system. If your Forth is PC-hosted, is there a reason to not use something like Python at the high levels?