Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Epic Fail Date: Fri, 11 Apr 2014 22:03:21 -0400 Organization: Aioe.org NNTP Server Lines: 146 Message-ID: References: <19597f37-fa23-478f-9a5f-b2aa66e89ae4@googlegroups.com> <2014Apr8.175427@mips.complang.tuwien.ac.at> <2014Apr9.181655@mips.complang.tuwien.ac.at> <64idnem648RzN9jOnZ2dnUVZ8iWdnZ2d@supernews.com> <2014Apr11.191612@mips.complang.tuwien.ac.at> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:29552 On Fri, 11 Apr 2014 13:59:19 -0400, Alex McDonald wrote: > The rest of my complaint stands, including the spurious claim that the > list below "creates all the "undefined" behavior for C" No, it doesn't. > Crays (supercomputer vector machines which were never programmed in C). > > DECs (included "Pemberton model" PDP-11, VAXen etc for which there were C > compilers). > > Burroughs (large systems ran Algol-based languages that predated C, and > there were no C compilers -- or assemblers). > > In other words, "undefined" C behavior has nothing to do with these > platforms. Where there is a C compiler, they are "Pemberton model". > > [inserted] > For some reason, the IBM mainframe entry got chopped. It is a "Pemberton > model" and might be considered the poster child for how we got to where > we are today; 8 bit byte, 32 bit (4 byte) address, contiguous memory, > two's complement arithmetic and so on. These machines had early C > compilers too. You clearly don't know what you're talking about. You previously stated things like ... There was no such language as PL/1. Yet, that's exactly what Stratus names their early standard PL/I language to differentiate it from IBM's PL/I. There are two aspects of this: 1) the machines where C was implemented, and 2) the machine architecture. This is going to get really long. Part 1) Let's start with the early machines where C was ported: PDP-11 (DMR,J&R) Honeywell 635 (DMR) IBM 360/370 (DMR,J&R) Interdata 8/32 (DMR,J&R) DEC VAX 11/780 (DMR,J&R) Honeywell 6000 (J&R) SEL86 (J&R) Data General Nova (J&R) Eclipse (J&R) Cray X-MP/24 (DM2) AT&T 3B20S minicomputer (BHKRS) AT&T 3B5 minicomputer (BHKRS) UNIVAC 1100 series (BHKRS) DMR - "The Development of the C Language", Dennis M. Ritchie J&R - "Portability of C Programs and the UNIX System, S.C. Johnson & D.M. Ritchie DM2 - "Experience with Unicos on the Cray X-MP", Dennis Ritchie BHKRS - "UNIX Operating System Porting Experiences", D.E. Bodenstab, T.F. Houghton, K.A. Kelleman, G. Ronkin, E.P. Schan As you can see, there are the Crays, DECs, IBMs, which I mentioned. What did you say about Cray never having been programmed in C? E.g., DM2 says: "Cray's C compiler, which is an instance of Johnson's PCC [1]." As for the Burroughs, it used linked activation records to create a stack, did have ALGOL implemented, but some have issues with creating pointers. This would be a difficult machine to put C onto. Supposedly, Steve Bartels implemented a C compiler for Burroughs. I don't know what generation of machine that's for or when that was done. He apparently worked on 6800/7800 series machines at least at one point in time. Supposedly, his Burroughs C compiler added an extra word to all malloc'd memory causing a NULL deference if accessed via a pointer scan. The Burroughs machines and their linked activation records are also rumored to be the reason that C doesn't explictly require a stack for procedures. I don't have anything that is "authoritative." Part 2) Let's cover the machine architecture issues of C: "The machines on which we first used BCPL and then B were word-addressed, and these languages' single data type, the `cell,' comfortably equated with the hardware machine word. The advent of the PDP-11 exposed several inadequacies of B's semantic model. First, its character-handling mechanisms, inherited with few changes from BCPL, were clumsy: [...]" -"The Development of the C Language", Dennis M. Ritchie "A major problem will occur when the computer's natural word size is not a multiple of its natural byte size." -"C: A Reference Manual", Harbison and Steele, 3rd Ed., pg 153. "Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices." -"Al Stevens Interviews Alex Stepanov", by Al Stevens, Dr. Dobb's Journal - Alex Stepanov is the C++ STL creator So, the C machine model will fail for a variety of reasons: 1) for a machine "word size not a multiple of byte size" (H&S) 2) for "integer of any kind" that is not "divisible evenly into bytes" (J&R) 3) for a word size being an odd multiple of char size (J&R) 4) for a "word-addressed machine that lacks any natural representation of a character pointer" (J&R) 5) when an object can't "be walked using a byte pointer derived from any kind of pointer into the object." (DAG) 6) when an object isn't represented as required by the C model of "[suitably] aligned byte arrays with additional properties (such as value interpretation) impressed upon them by the type system." (DAG) 7) when a char is less than 8-bits per byte (J&R) 8) when a short is less than 16-bits or a long is less than 32-bits (J&R) The C model fails in part on numerous early machines: 1) Cray's (H&S) (early were 16-bit word aligned) 2) unnamed 36-bit word, 7-bit char (e.g., IBM-705, PDP-10) (H&S) 3) PDP-11 due to 16-bit word alignment (R) 4) PDP-10 36-bit word using 7-bit char instead of 9-bit char (J&R) Sources: H&S "C: A Reference Manual", Harbison and Steele, 3rd, 1991 J&R "Portability of C Programs and the UNIX System" Johnson, Ritchie, 1978 DAG various usenet posts by Douglas A. Gwyn R "C Reference Manual" Dennis Ritchie, 1975 It appears that the PDP-7 would fail due to architecture too, since it has a 16-bit word and 6-bit char. Also, C requires 8-bits or more for a char. Albeit, that's an arbitrary constraint. Rod Pemberton