Timeline for Opaque objects on the stack / in structs
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 12, 2021 at 4:54 | vote | accept | dtech | ||
| Aug 10, 2021 at 22:13 | comment | added | dtech | I am playing it safe, primitives are aligned at their size, so I don't think there is room for unaligned access. I think the big exception to portability for me is the alignment of double, IRC it is 4 bytes on arm, I imagine for to save on padding, that will break the abi for regular struct code, while in this abi it is simply explicitly aligned at 8 bytes, so again - I don't think there is any room for unaligned access penalties. Unless I am missing something? | |
| Aug 10, 2021 at 20:22 | comment | added | amon | @dtech Fair enough, C is frequently used as a “portable assembly” language. If you need to access data structures with a specific layout there's no way around it. Might not be as portable as you expect though, e.g. if your code performs unaligned memory accesses. | |
| Aug 10, 2021 at 18:41 | comment | added | dtech | I don't have to ensure opaqueness, I just don't care to describe the content of the blob because none of that information is relevant to the usage of the object, all of which is driven by its layout information. This makes it significantly easier to generate portable code, provisioned by the underlying ABI design choices and composition rules. I basically don't have to change anything nor worry about mismatches with compiler/platform specifics. I don't really expect "good optimization", just slightly less bad compared to working with opaque pointers to heap memory and multiple indirections. | |
| Aug 10, 2021 at 18:28 | comment | added | amon |
@dtech Well, given those requirements just keeping everything as a char[] makes sense. But since this is a code generator you probably don't have to ensure opaqueness. Given that you're calculating offsets manually (and thus removing any useful type information from the compiler), I wouldn't expect good optimizations though.
|
|
| Aug 10, 2021 at 17:44 | comment | added | dtech | I also think that having those types as automatic storage blobs may help the compiler do a tad better at optimizing the code, even if it is just all pointer arithmetic and access internally. | |
| Aug 10, 2021 at 17:42 | comment | added | dtech | The intent is to write a code generator for a very small subset of C, it is already implemented as interpreter, but I'd like the option to accelerate it further by generative and compiling C code. Since the goal is to maximize performance, heap allocations and indirections are very undesirable, and I'd prefer for access to follow my specific ABI rather than generating a larger subset of C and having to deal with the quirks of compiler and platform differences in resulting layouts. Internally, all data is passed as as byte pointers, and members are addressed via layout info and pointer arith. | |
| Aug 10, 2021 at 16:46 | history | answered | amon | CC BY-SA 4.0 |