Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45809 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2016-03-03 16:24 -0800 |
| Last post | 2016-03-18 17:45 +0000 |
| Articles | 8 on this page of 108 — 21 participants |
Back to article view | Back to comp.lang.forth
OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 16:24 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-03 21:06 -0800
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:18 +0200
Re: OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 21:33 -0800
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:52 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 12:32 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 18:20 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-05 02:23 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-04 19:06 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:32 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:28 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 18:02 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-06 14:48 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-07 03:36 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:40 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 03:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:37 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 15:42 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:50 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:33 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 02:01 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 11:57 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-07 07:35 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-07 12:40 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:20 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 00:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 02:20 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 00:35 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-07 02:53 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 16:07 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-08 05:17 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:01 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:14 -0600
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 11:17 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-09 23:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 04:45 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-10 11:39 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-10 13:29 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:02 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 08:22 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 15:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-10 21:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-11 06:11 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-12 00:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 04:23 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 12:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 08:36 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:57 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:44 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 14:29 +0000
Re: OT: One of Anton's papers makes Hacker News "Elizabeth D. Rather" <erather@forth.com> - 2016-03-11 15:02 -1000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:20 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:53 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 13:02 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:52 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 12:42 -0600
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 13:12 -0600
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:20 +0200
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:37 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:23 -0800
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:24 -0600
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-04 21:01 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:51 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 19:43 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 01:45 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:24 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 12:27 +0000
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-13 13:50 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 19:52 +0000
Re: OT: One of Anton's papers makes Hacker News Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-13 16:08 -0400
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 13:40 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 00:41 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 18:23 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 02:59 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 20:29 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:44 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 16:23 -0700
Re: OT: One of Anton's papers makes Hacker News Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-03-14 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 17:19 -0700
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 19:26 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-15 00:48 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 22:30 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-15 07:23 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 10:09 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-15 08:56 -0700
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 19:33 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 09:46 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 09:37 -0400
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:40 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 13:53 -0400
Re: OT: One of Anton's papers makes Hacker News invalid <address@is.invalid> - 2016-03-17 18:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:37 +0100
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-18 14:36 +0000
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-14 09:17 +0100
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:56 +0000
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:00 -0500
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-15 11:22 +0100
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:38 +0000
Re: OT: One of Anton's papers makes Hacker News Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-03-14 01:40 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 01:02 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <ayrnieu@gmail.com> - 2016-03-14 07:29 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-18 17:45 +0000
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-03-15 11:22 +0100 |
| Message-ID | <nc8niv$g4s$1@dont-email.me> |
| In reply to | #46067 |
On 14/03/16 23:56, Bernd Paysan wrote:
> Am Mon, 14 Mar 2016 09:17:00 +0100 schrieb David Brown:
>> But it does /not/ operate on the same data types as machine
>> instructions.
>
> So you say, K&R are wrong? They may be wrong in the sense of that they
> designed their language around the PDP-11, and in the long run pretty
> much forced everybody to adopt the PDP-11-isms they used (and many of
> those constraints came actually from the IBM /360, which did set a lot of
> standards in a very diverse stone-age computing time).
If the PDP-11 had been the only machine around at the start of C, and no
other cpu ISA had been developed since, and the C standards had not
added 64-bit types, and if the PDP-11 had been in only one variant
without extensions, and if the C data types had matched that one exactly
- /then/ you could say that C operators on the same data types as
machine instructions.
Back in the real world, there is a reasonable correlation for a wide
range of systems - with C originally having data types matching closely
to those of the PDP-11 that K&R worked on at the time. But it is very
specifically /not/ an exact match, in order for C to work well on a wide
variety of architectures.
>
>> It operates on a set of types that are in most aspects
>> machine-independent, and in some aspects implementation-dependent. These
>> do not necessarily match the hardware - they were designed to be a
>> reasonable common-subset fit for a lot of the hardware in common use
>> when the language was created.
>
> That is a strange view about history. In 1970, data type diversity was
> much bigger than today. We had hardware which packed 10 6-bit characters
> (of course, all upper case) into one 60 bit word. We had one's and two's
> complement for integer, and floating point was very often BCD, or base
> 16. It was not easy to port C to some other processors of that time due
> to the PDP-11-isms in it. ANSI C reflects that diversity by being full
> of UB for things that really only diverged back then, and in the
> meantime, a consensus has formed.
>
> K&R did not make the language for all these strange hardware back then,
> of which very little has survived to today, their focus was on PDP-11.
> The hardware characteristics that have survived: byte addressed, two's
> complement machines, unsegmented address space, IEEE-style binary
> floating point, is not only shaping the C language, it is also shaped by
> the C language, as you state below. This is a mutual influence; though
> part of that influence was carried independently by the popularity of the
> actual popular architectures that had those properties (PDP-11 and
> others).
>
>> Processors - and therefore assembly
>> languages - have many features in their instruction sets and their data
>> types that are not directly available in C. A key example is that on a
>> processor, signed integer overflow is typically clearly defined - in C,
>> it is not.
>
> Just in *ANSI C,* it is not. E.g. GCC recently (in version 5) got
> extensions for that, after they axed the access to wraparound in GCC 2.95
> more than a decade ago, and added it back as a compiler switch with -
> fwrapv soon due to demand of their user base.
>
-fwrapv is from gcc 3.4, in 2004, so it is not /that/ recent.
Yes, some people want two's complement wrapping for their signed
integers, so gcc provides it as an option which gives predictable
behaviour at the risk of illogical behaviour (adding two positive
numbers can give you a negative result) and at the cost of disabling a
few optimisations (I am not going to claim that this has a major effect
on code efficiency, mere that it has /some/ effect).
> Using -fwrapv, you can detect signed overflow just the same as unsigned
> overflow (where the standard has defined mod 2^n behavior) pretty much in
> the same way you can for unsigned (where b<0 is always false):
>
> int a, b; ...
> if(b<0 ? a>=a+b : a<a+b) { <addition overflow> }
>
> This is C, it is only non-nasal-daemon-C; it is very obvious that this if
> triggers only on an overflow (regardless of actual integer
> representation). A compiler writer who wants to speed up real-world
> programs would detect this pattern and convert it to just two
> instructions: add a,b and jump on overflow.
It is C - but it is not standard C. It is an implementation-specific
dialect of C. (Actually, it /is/ legal standard C - but in standard C
the compiler can assume the overflow will never happen. So it only
works as the programmer intended in a implementation-specific dialect of C.)
>
>> But equally clearly, small processors will not support data
>> types such as 64-bit integers or floating point - but C gives you them
>> on such devices.
>
> I've seen Keil C on an 8051. There was neither 64 bit (or 32 bit) nor
> floating point support (they later added FP support, and also cleaned up
> some rough corners). There are some weird restrictions, too, but in
> general, the Keil compiler provided pretty much what I think a "portable
> assembler" for the 8051 should look like: all the extensions that are
> needed to access the the features of the hardware, all the restrictions
> that come with that underpowered CPU, and an efficient way to map the
> code to that tiny processor. Once you understand the limitations, you
> can write code that works on a PC and on Keil; though of course, a lot of
> code written for the 8051 will be inherently non-portable (accessing
> SFRs).
Certainly a particular implementation of C can provide enough extras to
be considered a direct replacement for an assembler on that target - but
clearly it is no longer a /portable/ assembler! The standard, portable
C code may work on a PC and Keil 8051 - but not the assembler-like bits.
(gcc on the 8-bit avr supports floating point and 64-bit integers. I
can't remember off-hand if it supports 64-bit doubles, or cheats and
uses 32-bit for float and double.)
>
> If you have an armel Linux or Android system, where software floating
> point emulation is enabled, it's not C that provides the floating point.
> The compiler just has to limit itself to those instructions of the ARM FP
> ISA that is emulated. Same with x86; in the 386 days, I had my software
> floating point emulator, but C compiled 80x87 instructions. The
> emulation layer did cost performance, it would have been faster if the
> corresponding code was called directly.
No, that is not how it works at all, at least on most targets and most
compilers. C specifies how floating point will work (with a certain
amount of implementation-defined wiggle room). If the cpu hardware can
handle the calculations directly, the compiler will use those
instructions. If not, the compiler will do the calculations in
software. The compiler certainly will not attempt to emulate the
hardware - that would be seriously inefficient in most cases. Why waste
effort trying to get /exactly/ the same rounding if it is not required?
Why waste effort trying to emulate flag bits? Of course compilers
don't do that.
And the opposite is true in many situations - I have used embedded
processors with floating point hardware that cannot handle unusual
numbers (NaNs, denormals, etc.). Because the compiler supports IEEE
floating point standards (not actually required by the C standards), it
has to generate a certain amount of additional code before using the
hardware floating point instructions (unless you use compiler switches
to relax the standards conformance).
On some systems, it used to be the case that you wanted a single binary
that would run fast with floating point hardware, and where the OS
provided a floating point emulator if the hardware is not available. To
my knowledge, such techniques are very rare now. And even when they
were used, then as far as the compiler was concerned you had floating
point hardware support - the emulation was separate.
>
> 64 bit data types (register pairs) on 32 bit is used as output of
> widening multiplication, also as input for shifts, and input of divisions
> on most 32 bit architectures, but C makes the data type more useful, by
> also providing other operations. C's support for add with carry is non-
> existing, but the double-sized data type allows to express it.
>
>> And modern processors are designed to have data types that fit with C,
>> rather than the other way round.
>
> Yes, well observed, that influence is two-way, especially due to C's
> popularity. But they still have their add operation defined as if it was
> fit for Forth, not for ANSI C: don't care about the sign, just wrap
> around, use the same instruction for signed and unsigned addition. Can't
> be influence from Forth, because Forth's popularity is much lower than
> C's. Forth, of course, was also shaped by the popular 1970 architectures
> like PDP-11, so it's that influence.
My knowledge of Forth is rather limited - I played with it a bit some 25
years ago, and have only tracked it a little since then. (We had a
project once a good many years back where we considered using a 4-bit
microcontroller - it had a stack-based ISA and a Forth-like language.)
And I know nothing about how Forth may or may not have influenced cpu
architectures.
However, the reason that signed addition works as two's complement
wrap-around in almost all cpus has nothing to do with Forth or C - it is
purely because that is the simplest and fastest way to implement it in
the hardware. If you want to be able to add and subtract data in an
efficient way, and are happy to ignore the behaviour on overflow, then
two's complement is easier than any other solution.
>
>> There are lots of types of programming that are possible in assembly,
>> but completely impossible in (standard) C. You are very limited in your
>> access to hardware, you cannot access hardware registers other than
>> memory-mapped peripherals, you have no control over the timing of code,
>> you have little control over the ordering (volatile accesses are
>> ordered, but not calculations or non-volatile accesses), you cannot
>> interact with interrupts (except in a very limited way with signals),
>> you cannot implement multi-threading, atomic accesses, etc. (you can
>> /use/ these features in C11, but you cannot write the underlying
>> implementations in standard C), you cannot (at least not efficiently and
>> conveniently) use co-routines or other types of control-flow structuring
>> outside the limits of C.
>
> There are certainly some aspects of assembler where C is inadequate (even
> when implemented in a friendly way), or at least requires adding a few
> asm-statements. Not all of the list above is fair: The core of a low-
> level language should be those features that cannot be implemented in
> that language; so not being able to implement atomic operations based on
> the rest of C is not a deficit, but rather suggests adding these
> operations to the language standard.
The path chosen by the C (and C++) standards was to add atomic types and
operations to the standard library. Thus C programs can /use/ atomic
types - but the library functions needed to support them cannot be
written in pure C. That is, I think, a perfectly good compromise - the
library can use target-specific features (including inline assembly) in
order to let user code be target independent.
>
>> C is the language that it is - with its benefits and its disadvantages.
>> It does not completely replace assembly, but certainly many programs
>> that used to be written in assembly could be written more conveniently
>> in C (or at least mostly C). In the same way, many programs that have
>> traditionally be written in C could be written more conveniently in C++,
>> Python, or a host of other higher level languages that have different
>> balances between safety, ease-of-use, functionality, efficiency, etc.
>
> Fully agreed on that. The expression "portable assembler" IMHO just
> means that: while it can't fully replace assembler in all corner cases,
> only very little assembler should be needed (IIRC, K&R provided some line
> counts of the remaining assembler part in Unix in the first edition, was
> it some hundred lines of code?), and for more high-level stuff, there are
> a bunch of other languages which do a better job, depending on your
> expectations (none of them do all jobs better than the others).
>
I believe we agree (at least approximately) on what can and cannot be
done in C, and what needs assembly. It is a question of definitions.
We might agree that an assembly microcontroller program could be
re-written with 99% portable standard C with 1% assembly or
target-specific instrinsics. Porting the code to a different processor
(with the same peripherals - an unlikely situation, but not impossible)
means keeping the 99% portable C and replacing the 1% assembly. To you,
the 99% commonality means C is a "portable assembler" - to me, the 1%
difference means that C is /not/ a portable assembler.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-14 22:38 +0000 |
| Message-ID | <56e73caa.3486218@news.xs4all.nl> |
| In reply to | #46047 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sun, 13 Mar 2016 13:40:26 -0700 schrieb Keith Thompson: > > Even if that were true (it isn't), that doesn't make C a "portable > > assembler". Other operating systems had been written in assembly > > language. Unix was written in something that was *not* assembly > > language. > > Whatever, the most relevant answer here derives it from three statements > of the introduction of K&R's first edition: > > http://stackoverflow.com/questions/3040276/when-did-people-first-start- > thinking-c-is-portable-assembler > > "C is a relatively "low level" language. This characterization is not > pejorative; it simply means that C deals with the same sort of objects > that most computers do, namely characters, numbers, and addresses. > [ ... ] > > Again, because the language reflects the capabilities of current > computers, C programs tend to be efficient enough that there is no > compulsion to write assembly language instead. > [ ... ] > > Although C matches the capabilities of many computers, it is independent > of any particular machine architecture, and so with a little care it is > easy to write "portable" programs ..." All of which proves that C is a programming language which can be used to _not_ program in assembly language, rather than a portable version of assembly language itself. > The next thing you probably refute is that K&R developed the programming > language C. I should bloody well hope so! Dennis Ritchie developed C, Brian Kernighan "only" wrote the book, _not_ the language. > There's a lot of nonsense in the discussion above, of people who studied > C "the hard, academic way You know fuck-all about me, yet you think you know everything. What a surprise from a FORTH-head... getting things backwards _does_ become a habit, doesn't it? Richard
[toc] | [prev] | [next] | [standalone]
| From | Randy Howard <rhoward.mx@EverybodyUsesIt.com> |
|---|---|
| Date | 2016-03-14 01:40 -0500 |
| Message-ID | <nc5mc1$1o2c$1@gioia.aioe.org> |
| In reply to | #46038 |
On 3/13/16 2:52 PM, Albert van der Horst wrote: > C, Unix and the Bourne shell were create at one time to cooperate. > Unix was the first operating system not written in assembler, > and C was used to write it, making Unix a portable OS. Not sure where you are getting this mythology from, but you may want to double-check your sources. -- Randy Howard (replace the obvious text in the obvious way if you wish to contact me directly)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-06 11:00 +0000 |
| Message-ID | <2016Mar6.120003@mips.complang.tuwien.ac.at> |
| In reply to | #45846 |
Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
>"However, this implementation is C*, but not ``C'',
>because p<q is not defined in ``C'' if p and q point
>to different objects."
>
>That is a completely wrong conclusion.
Well, go over to comp.lang.c[.std] and ask them about the standardness
of the implementation I give in the paper. I am sure they will cite
verse and chapter of the C standard on that.
The funny thing is that in the beginning I did not know that one
cannot implement memmove() in standard C. I suggested an efficient
implementation of the overlap check
<2015May1.155805@mips.complang.tuwien.ac.at>:
| if ((size_t)(dest-src) < len)
(which Forther's will realize corresponds to WITHIN)
But my experience with C language lawyers led me to write:
|Of course, since this code contains more than three tokens, it is
|likely to contain undefined behaviour, so let's express this in a more
|reliable language:
|
| movq %rdi, %rax
| subq %rsi, %rax
| cmpq %rdx, %rax
| jb ...
And indeed it turned out that the C code above is non-standard
<cqhr5oF1daiU1@mid.individual.net>. In the following discussion, it
turned out that even the simple variant shown in the paper is
non-standard.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-07 19:19 -0500 |
| Message-ID | <20160307191929.272a5c85@_> |
| In reply to | #45887 |
On Sun, 06 Mar 2016 11:00:03 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes: > Well, go over to comp.lang.c[.std] and ask them about > the standardness of the implementation I give in the paper. > I am sure they will cite verse and chapter of the C standard > on that. ... > The funny thing is that in the beginning I did not know that > one cannot implement memmove() in standard C. Did you even read the standard? It tells you exactly how you can implement memmove() in standard C without any UB (undefined behavior),i.e., by using a temporary, intermediate buffer. It also hints that the preferred method for implementing memmove() is to use IB (implementation behavior), not UB. I.e., starts with "as if". C99 (12/01/1999 2nd Ed., ISO/IEC 9899:1999(E), not a draft) C99 7.21.2.2 The 'memmove' function, pg 325 "The 'memmove' function copies n characters from the object pointed to by s2 into the object pointed to by s1. Copying takes place as if the n characters from the object pointed to by s2 are first copied into a temporary array of n characters that does not overlap the objects pointed to by s1 and s2, and then the n characters from the temporary array are copied into the object pointed to by s1." FYI, P.J. Plauger, an ANSI X3J11 C committee member, uses pointer comparisons in his implementation of memmove() for his C library book which is 100% ANSI C compliant and the basis of the C library used by Dinkumware. His C library passes the Plum Hall C Validation Suite for C compliance. So, maybe, there is some other rationale which allows memmove() to work with supposed UB pointer comparisons of "In all other cases, the behavior is undefined." in C99 6.5.8 sub 5 pg 85. I.e., it uses IB or it's assumed that the user will only use overlapped memory regions for memmove(). Also, see my reply to Bernd as to why complying with that phrase for pointer comparison being UB breaks C in many ways. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-08 01:02 +0000 |
| Message-ID | <nbl8ag$e55$2@dont-email.me> |
| In reply to | #45926 |
Am Mon, 07 Mar 2016 19:19:29 -0500 schrieb Rod Pemberton: > Also, see my reply to Bernd as to why complying with that phrase for > pointer comparison being UB breaks C in many ways. I agree with you that it would be horrible if that was UB, but it actually is UB, not IB, and the nasal daemon compilers can then use that property to break a hell lot of code. Anton's paper is an argument *not* to interpret the C standard in that way. Your quote from Plauger supports Anton's mission. IMHO, Plauger simply doesn't apply the nasal daemon rule for UB, but thinks that this pointer comparison can only return either 0 or 1, and when the objects are different, it doesn't matter: memmove will always work as it should. I.e. it is undefined if it returns 0 or 1 for not-the-same-object pointers, but it certainly will return either 0 or 1. The nasal daemon compiler maintainers differ: UB can cause nasal daemons. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2016-03-14 07:29 -0700 |
| Message-ID | <9d140767-4c8f-4c20-8a19-62a4456f98da@googlegroups.com> |
| In reply to | #45809 |
On Sunday, March 13, 2016 at 7:27:14 AM UTC-5, Albert van der Horst wrote: > > Note that I've cross posted to comp.lang.c. > As technical problems drag on, non-technical contributors to the problem are found. They start as scribbles in the margins of the secret summary of What Happened Here: "this would be over already if only Bob wasn't on this team or wasn't the CEO's nephew." They grow into footnotes: "we lost two weeks of productivity because we let Alice suggest this to the team lead -- who naturally argued with her about it. In the future we should let non-controversial people propose non-controversial measures, and save the arguments for when there might be a benefit to it." They become entire chapters. Chapter title: "The Contributions of our Distant Corporate Overlords". For the truly epic technical problems, the actual technical issue must finally itself shrink to a footnote, or a scribble on a margin, in a book focused on all of the defective personalities that kept anyone from seizing on a solution for so long. I think Anton and Bernd are not yet at the stage of castigating people in the margins. Anton wrote a paper that was purely on the technical issues here, and he could've really juiced up the language if there was no expectation at all that a C maintainer might actually read and be convinced by his points. Bernd kept his irritation with Keith Thompson's elaborate proof that C is not literally an assembler language to a brief opening remark and then replied usefully to that proof. I said "not yet", but of course not all problems *do* have a CEO's nephew in them. If you'd asked me, just prior to Albert's crossposting to comp.lang.c, why this technical problem (of GCC's deteriorating ability to be a compiler for gforth) has been going on for so long without a correction, I might've summarized my answer with these potential contributors to the problem: 1. Some guy made a very funny joke about nasal demons and C programmers have come to believe that it is actually a wise principle of compiler design. 2. C compiler maintainers have come to compete in terms of SPEC results, which has blinded them to the real-world consequences of their developments. 3. C compilers maintainers have as their customers both humans hand-writing C and also other languages with compilers that generate C. While gforth's maintainers have become unhappier over time, the opposite mood is seen with Mercury's maintainers where the "high level C" target is now substantially better than previously superior "asm_fast" and similarly low level targets - and purely because C compilers have improved so much at chewing up masses of machine-generated code. (Of course, C++ must be an even more impressive language of this type.) After reading the extremely erudite and fine posts of the people of comp.lang.c, who I now imagine are not even condescending to speak to us through computers, but whose words are actually being transcribed to us by a team of servants that attend them at their fine dinner parties, I have a new item for this list. A non-technical one. It is this: C is right above COBOL in terms of language sexiness. It is regarded as much more useful -- but shovels and wheelbarrows are useful. Everyone is expected to know what little there is to know about it, and then to grow beyond C in order to learn some actually interesting facets of "higher level" languages that have academic papers and exciting conferences and screencasting ninjas and so on. C is boring and simple, and for you to say "I know C" does not impress anyone. Not that you aren't useful. But-- could you please go move these rocks from this pile to that pile so that I could chat with these "Ladies in JavaScript" speakers? Or anyone but you. C doesn't have monads or DSLs or novel models of memory management. C isn't "an adequate lisp". Somehow even Forth people -- users of a language without an array type! -- look down on C as a language and can add silly things like 'quotations' and 'backtracking' to their language with just a little bit of systems knowledge. It is even asserted that you can know all there is to know about C by reading a single book. Where is C's "Thinking C" or "Scientific C" that gets a community revival after the Amazon copies get up in price? But, C communities still exist. C people must exist in them. The people in them must contrive to look down on new entrants to these communities. How do these people survive without turning into creatures like WJ who just post all the time about how much better other languages are? They have found a way. You simpletons! Don't you know that NULL isn't *necessarily* defined as (void*)0? Don't you see all the undefined behavior in that function of yours? Have you overlooked that sizeof(x) does something completely different if x is an array of ints rather than a pointer to ints? Bow before me, a long-bearded master of ANSI C : an extremely difficult language. You may, if you listen to me enough, and carefully enough, one day manage to use it without regularly summoning demons through your nostrils. But, if this attitude contributes to C compilers' sneering miscompilation of code, what's the solution? If you destroy the wizards who are self-importantly screwing things up, who will be left to keep working on the compilers? -- Julian
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-18 17:45 +0000 |
| Message-ID | <2016Mar18.184547@mips.complang.tuwien.ac.at> |
| In reply to | #46056 |
Julian Fondren <ayrnieu@gmail.com> writes:
>3. C compilers maintainers have as their customers both humans
>hand-writing C and also other languages with compilers that
>generate C. While gforth's maintainers have become unhappier
>over time, the opposite mood is seen with Mercury's maintainers
>where the "high level C" target is now substantially better than
>previously superior "asm_fast" and similarly low level targets -
>and purely because C compilers have improved so much at chewing
>up masses of machine-generated code. (Of course, C++ must be an
>even more impressive language of this type.)
Actually the performance-critical part of Gforth is also mostly
generated by a generator (called vmgen as a productized version). It
was already compiled to nice code with gcc-2.x; after all we built the
generator to make use of the capabilities of this compiler, and
perform optimizations by itself that are not present in gcc-2.x. In
particular, vmgen relies on register allocation, copy propagation, and
dead load elimination (occurs in, e.g., DROP). It does not rely on
the compiler eliminating redundant stores to memory (as in DUP) and
has some extra code for eliminating such stores.
Concerning Mercury, the question is: Are the improvement due to
optimizations* or "optimizations"? I suspect the former. If I find
the time to check this, where do I find more about this, in particular
benchmarks on which the claim above is based?
>But, if this attitude contributes to C compilers' sneering
>miscompilation of code, what's the solution? If you destroy the
>wizards who are self-importantly screwing things up, who will be
>left to keep working on the compilers?
There is enough C code around that there is a good incentive to
maintain a C compiler. If the current maintainers of gcc and clang
vanished, or decided to get rid of the C front end, some other people
would work on a C compiler (not necessarily gcc and clang), because
it's an itch to scratch. Having a C* front end is also an itch to
scratch, but at the moment the itch is not bad enough that people have
found themselves that are willing to go head-to-head against the
current gcc and Clang maintainers.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web