I need a new compiler...
in [Cobol]
|
Prev: COBOL/CICS/DB2 - COBOL for MVS and compile option DYNAM -solution from 2006
Next: Still one more Overlapping operands test
From: Howard Brazee on 15 Dec 2008 10:27 It's pleasant to be able to put things in specific categories. This seems to be more pleasant for people with methodological (as opposed to artistic) minds - such as programmers. But after we have come to a consensus about where a particular thing (such as C) belongs - it really hasn't been molded to fit the way we wish. The real world isn't as easily categorized the way we wish. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Michael Wojcik on 15 Dec 2008 11:21 Bill Gunshannon wrote: > In article <34h5k4td4l98q98308mkg2ri53h0raakvg(a)4ax.com>, > Howard Brazee <howard(a)brazee.net> writes: >> I remember reading about a chip that was used Java p-code natively. > > That was done with UCSD P-code by the Western Digital Pascal Microengine > a couple of decades ago. Yet another wheel re-invented. In what way was this reinventing a wheel? The various proposed Java "accelerator" chip designers were well aware of other implementations of pseudocode engines in hardware, and similar projects. (There were hardware LISP implementations, hardware APL implementations, hardware simulators for other machines...) None of those executed Java bytecode, so of course they had to create new hardware to do that. When I write a program, the existence of other programs doesn't mean I'm reinventing the program wheel. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 15 Dec 2008 11:35 docdwarf(a)panix.com wrote: > > If C, in fact, does *not* 'provide low-level access to memory' and is does > *not* have a 'primary use is for "system programming", including > implementing operating systems and embedded system applications, due to a > combination of desirable characteristics such as code portability and > efficiency, ability to access specific hardware addresses, ability to > "pun" types to match externally imposed data access requirements' then it > would seem that I am incorrect. > > (quoted material above taken from > http://en.wikipedia.org/wiki/C_(programming_language) ... me, I'se jes' a > COBOL-codin' fool) This is one of the dangers of using Wikipedia as a source: it is frequently incorrect. In this case, it's wrong about "provid[ing] low-level access to memory", which is not a feature of the C language. It is a feature of some implementations of C, and some languages which are "extended" versions of C. ISO 9899-1999 is, of course, the authoritive source; but the comp.lang.c FAQ would also have cleared up this misconception. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 15 Dec 2008 11:27 PR wrote: > > Just go write a few thousand lines of PDP-11 Macro Assembler I've seen plenty. > and you > will never again doubt that C is in fact a "portable assembler" Oh, yes I will. The "portable assembler" claim has always been at best a hyperbolic metaphor that captures only a few of C's characteristics. It's no longer a useful characterization, particularly in light of the language's evolution. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 15 Dec 2008 11:32
PR wrote: > On Dec 12, 11:29 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >> docdw...(a)panix.com wrote: >> >>> It is a compiled language, true, but still provides low-level >>> system/memory/device access in an Assembley-like manner. >> No, it doesn't. Some C implementations may extend the language to >> provide direct access to memory and devices (whatever that may mean on >> the platform), but that's not part of the C language. > > Actually, yes it it. No, it is not. I suggest you read ISO 9899-1999 (plus Technical Corregida), which is the definition of the C language. You will find that it does not require implementations to "provide low-level system/memory/device access", and indeed does not define any language constructs which remotely resemble anything such "access" might include. > Access to memory is always defined in C, as > pointers are intrinsic. C pointers do not need to provide access, "low-level" or otherwise, to physical memory or devices. They need to support the dereference operator, and so could be considered as providing access to "memory" in the sense of the abstract machine, but there is *absolutely no requirement* that such access have any particular relationship to the hardware. > And pointers are not special variable types, Indeed. They have pointer type, which is not "special" (whatever that might mean). But it's not any other kind of type, either. > they originally were integers, and for the most part, still are. Originally, yes. As the language is currently defined, no. Type punning between pointers and integers invokes Undefined Behavior. That it works in some implementations is beside the point. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |