4 ms·

All the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there

All the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there the bulk of work is creating control structures in memory and then kicking them through a port or a coprocessor instruction). C/C++ are perfect for the memory manipulation even in their purest standard form. I imagine your concern is about deriving the addresses for register apertures or emitting specific opcodes? For the concrete addresses you just link with the symbols defined outside of your C code. Special ops cannot be done in pure standard, but this is not an issue in practice as there are no pure standard compilers. Even for app development you want intrinsics just for the vector, cache and bit instructions.

pjmlp 13y ago
No, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler. You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs. There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.
- pandaman 13y ago
  I guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).
  - pjmlp 13y ago
    I was just playing devil's advocate a bit, because many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard. Many mainstream languages, with AOT native compilers would be as usable.
    - pandaman 13y ago
      Most developers never read the standard in the first place. I don't see how is this important though. We did not have a standard till 1998, yet somehow managed to use C++. Same as with C, which had been used very successfully standard-less for almost two decades.
      - pjmlp 13y ago
        > Most developers never read the standard in the first place. I don't see how is this important though. Do you write portable code in C and C++ across disparate systems and OSs, using multiple compilers? I used to do that between 1994 and 2001. Don't miss those days of hit-and-miss about compiler support. > We did not have a standard till 1998, yet somehow managed to use C++. Yes we did. It was called the Annotated Reference Manual, used as basis for the standard, coupled with articles from The C++ Report, The C Users Journal (latter The C/C++ Users Journal). > Same as with C, which had been used very successfully standard-less for almost two decades. It works if you only care about one specific compiler. On those days the standard was the AT&T UNIX compiler.
        pandaman 13y ago
        Obviously, you cannot write portable system code. You can do conditional compilation to target multiple platforms though. And when you do that you realize two things: 1. No compiler is fully compliant with any standard. 2. Every compiler has bugs so even the compliant parts can be unusable. And then you realize it's not a big deal. Changes between platforms are greater than changes between compilers. When your targets have different endianness or, even better, mixed endianness between different PUs - the standard compliance of your code is the least of your worries. >It works if you only care about one specific compiler. Also works if you care about a finite number of specific compilers and architectures. >On those days the standard was the AT&T UNIX compiler. There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.
        pjmlp 13y ago
  - pkolaczk 13y ago
    Java does support memory manipulation by DirectByteBuffers.

pjmlp 13y ago

No, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler. You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs. There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.

pandaman 13y ago
I guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).
- pjmlp 13y ago
  I was just playing devil's advocate a bit, because many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard. Many mainstream languages, with AOT native compilers would be as usable.
  - pandaman 13y ago
    Most developers never read the standard in the first place. I don't see how is this important though. We did not have a standard till 1998, yet somehow managed to use C++. Same as with C, which had been used very successfully standard-less for almost two decades.
    - pjmlp 13y ago
      > Most developers never read the standard in the first place. I don't see how is this important though. Do you write portable code in C and C++ across disparate systems and OSs, using multiple compilers? I used to do that between 1994 and 2001. Don't miss those days of hit-and-miss about compiler support. > We did not have a standard till 1998, yet somehow managed to use C++. Yes we did. It was called the Annotated Reference Manual, used as basis for the standard, coupled with articles from The C++ Report, The C Users Journal (latter The C/C++ Users Journal). > Same as with C, which had been used very successfully standard-less for almost two decades. It works if you only care about one specific compiler. On those days the standard was the AT&T UNIX compiler.
      - pandaman 13y ago
        Obviously, you cannot write portable system code. You can do conditional compilation to target multiple platforms though. And when you do that you realize two things: 1. No compiler is fully compliant with any standard. 2. Every compiler has bugs so even the compliant parts can be unusable. And then you realize it's not a big deal. Changes between platforms are greater than changes between compilers. When your targets have different endianness or, even better, mixed endianness between different PUs - the standard compliance of your code is the least of your worries. >It works if you only care about one specific compiler. Also works if you care about a finite number of specific compilers and architectures. >On those days the standard was the AT&T UNIX compiler. There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.
        pjmlp 13y ago
- pkolaczk 13y ago
  Java does support memory manipulation by DirectByteBuffers.