On Tue, Jan 30, 2018 at 9:39 PM, Jon Perryman <jperr...@pacbell.net> wrote:
> > C is a byte by byte language. Anything not hidden in a primitive or > function must be processed byte by byte. In primitives and functions, the > compiler can choose how to implement it. The point is C programmers must > process byte by byte unless they can find a function. > > I'm sorry, but can't agree with anything of this. 1) Compilers can generate machine instruction implementations that take advantage of the instructions and architecture available. Even if you write byte-by-byte code, a compiler may rewrite it to use zArch instructions that are not byte-by-byte but equivalent. This is distinctly different from how assemblers work. 2) The "C Standard Library" is part of the C language standard(s). For all of the supposed byte-by-byte C programmers that can't find any functions to use, here are links to the XL/C++ documentation, where the "Runtime Library Reference" can be found: https://www-01.ibm.com/support/docview.wss?uid=swg27036892 The bottom line is that this: memcpy(field1, field2, sizeof(field1)); generates an MVC instruction (or several or a loop or an unrolled loop of MVC instructions). To say that the "C Language" is byte-by-byte is pedantic. 3) I also do not agree with your repeated assertion that it means something significant that C was originally developed on a RISC machine ( I believe that it was a PDP-7) with only certain instructions. I would have thought that this kind of argument about the relative benefits of assemblers vs compilers (or assembler vs C) would have been over a couple of decades ago. A more current argument is static vs dynamic (VM+JIT) compilation.
