5 ms·
The types that C knows about are the types that the assembly knows about. Strings, especially unicode strings, aren't something that the raw processor knows ab
by lanstin 2y ago
The types that C knows about are the types that the assembly knows about. Strings, especially unicode strings, aren't something that the raw processor knows about (as far as I know). At the machine level, it is all ad-hoc juggling of buffers without a reliably tracked size, until you impose constraints like only use length-prefixed protocols and structures. Where "only" is difficult for humans to achieve. One slip up and wham.
- pornel 2y agoC with its notion of an object, TBAA, and pointer provenance is already disconnected from what the machine is doing. The portable assembly myth is a recipe for getting Undefined Behavior. C is built on an abstract machine described in the C spec, not any particular machine code or assembly. Buffers (objects) in C already have an identity and a semantically important length. C just lacks features to keep track of this explicitly and enforce error handling. Languages exist to provide a more useful abstraction on top of the machine, not to naively mirror everything even where it is unhelpful and dangerous. For example, BCPL did not have pointer types, only integers, because they were the same thing for the CPU. That was a mess that C (mostly) fixed by creating "fictional" types that didn't exist at the assembly level.
- bluGill 2y agoThe abstract machine of C is defined with careful understanding of what real CPUs do.
- pjmlp 2y agoIn need of a copy of ISO C printout?
- bluGill 2y agoThe people who define Cs abstract machine are well aware of what real hardware is like. The standard of course doesn't mention real hardware but what is in there is guided by real hardware behaviour. they add to the specs when a change would aid real implementation
- pjmlp 2y agoHow does AVX512 guide ISO C?
- bluGill 2y agoThe ommitte empers have been awareof simd for a long time and asking that. So far they have either not agreed, or because they have seen no need because autovectorization has shown much promise without. (that is both of the above are true though not always to the same people) multi core is where languages have had to change because the language model of 1970 wasn't good enough.
- pjmlp 2y agoIt was an example among many others. How does (FPGA, HiLow, Havard, CUDA, MPI,...) guide ISO C?
- bluGill 2y agoHow should they? in some cases they have decided that isn't where they want c to go, in others the model of 1970 is still good enough, and in others they are being slow (possible intentional to not make a mistake)
- lanstin 2y agoYou must be thinking of c++? There is no object in C just structs which is just a little bit of organization of the contiguous memory. C exists to make writing portable CPU level software easier than assembler. It was astonishingly successful at this niche; many more people could write printer drivers. While ptr types may not formally exist in assembly, the variety of addressing modes using registers or locations that are also integers has a natural resonance with ptr and array types. I would say C precisely likes to mirror everything even where it is unhelpful and dangerous. The spirit is captured in the Hole Hawg article: http://www.team.net/mjb/hawg.html http://www.team.net/mjb/hawg.html It is the same sort of fun one has with self modifying code (JIT compilers) or setting 1 to have a value of 2 in Python. ed: https://en.cppreference.com/w/c/language/object https://en.cppreference.com/w/c/language/object is what is being referred to. I'm still pretty sure in the 80s and 90s people thought of and used C as a portable low-level language, which is why things like Python and Linux were written in C.
- pjmlp 2y agoC has objects in the context of how the Abstract C Machine is defined by ISO C standard, nothing to do with OOP.
- pjmlp 2y agoAssembly only knows about raw bytes, nothing else.
- aidenn0 2y agoDepends on the assembly, but even most (all?) RISC instruction sets know about words (and probably half-words too) in addition to bytes.
- pjmlp 2y agoPairs, quads and octects of bytes.
- eru 2y agoThere's also vector instructions.
- pjmlp 2y agoOperating on stream of bytes, defined by registers.
- eru 2y agoThe context was this comment: > Depends on the assembly, but even most (all?) RISC instruction sets know about words (and probably half-words too) in addition to bytes. Of course, you could define words and half-words in terms of bytes, too. Just as you can do with vectors. And many vector instructions operate more on eg streams of words than streams of bytes.
- pjmlp 2y agoNope, the context was: "The types that C knows about are the types that the assembly knows about."