4 ms·

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `attribute((section("t

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I understand that there aren't many use-cases for these specific features, but I have an unusual direct-threaded VM which relies on some of them, and the only real alternative I see is to write plain assembly.

zyedidia 4y ago
I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the same as with GCC. Note: the @register feature is new with GDC 13. See here for the docs: https://gcc.gnu.org/onlinedocs/gdc/ https://gcc.gnu.org/onlinedocs/gdc/. And of course LDC supports all the LLVM custom attributes, plus GCC-compatible inline assembler (not sure about the "g" constraint though) and LLVM-style inline assembler.
- sparkie 4y ago
  Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.
  - zyedidia 4y ago
    Depending on how much language support you want, you may want to compile without the D runtime (in which case you only have access to the C standard library, and various features are disabled, such as classes/interfaces, garbage collection, exceptions, and most of the D standard library). You can disable the D runtime in GDC with -fno-druntime and in LDC with -betterC. With those flags, the basic hello world program looks like this: import core.stdc.stdio; extern (C) void main() { printf("Hello world\n"); }
WalterBright 4y ago
The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are needed for special purposes. Gcc may be the most suitable language if you need those extensions. What I would do is use gcc for the parts of the code that need those extensions, and D for the rest (D code can directly interact with C code).
- sparkie 4y ago
  Thanks. My root comment mentioned that it was not really the features of C that I depended on, but the GCC specific features. I'm interested in using D now as sibling comment mentions that I can use some of these features in gcd, but I'm not yet sure how much benefit I'd get over using C by using a subset of the D features which are compatible with the constraints of my VM.
  - WalterBright 4y ago
    One big feature is D has modules. There's no reason C can't have modules, but they don't. You don't need to code .h files anymore.
- mhh__ 3y ago
  LDC and GDC both have the section concept exposed as a UDA.
  - WalterBright 3y ago
    Good!
srcreigh 4y ago
GNU jitter right? I’ve seen (a few?) highly detailed slide decks about it. Extremely cool stuff I found this pdf but I thought there was a different one, anyone link to that? https://binary-tools.net/jitter-binary-tools-summit.pdf https://binary-tools.net/jitter-binary-tools-summit.pdf
- sparkie 4y ago
  Not jitter, but I'm familiar with it and have used some of its ideas. (More Jitter slides referenced on Luca Saiu's page:https://ageinghacker.net/talks/#jitter-talks https://ageinghacker.net/talks/#jitter-talks) The (experimental) VM I'm working on embeds type information into pointers. I place some functions at fixed virtual addresses and use the type information from the pointer to materialize these addresses at runtime, without having to dereference any pointers until I actually call the function. Essentially, if you have a pointer you will know the type of value it points to from the pointer itself. This method places some tight constraints on how memory can be allocated, but I don't think it will be too much of a limitation for most applications intended to run on it. I have 12-bits in a 48-pointer which provide type information, which leaves a maximum 36-bits of virtual address space per type (or 35 bits if you discount the most significant bit which refers to kernel space). I'm currently using the section attribute to implement it, but I'm aware there are other methods to achieve this. I could do it at runtime by `mmap`ing the virtual memory and then loading in the machine code at the addresses I need. This method might be more flexible in the long run and would free me up from using GCC specific attributes.
GoblinSlayer 3y ago
Linux is reportedly written in C and it still has a good share of plain assembler.

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t

zyedidia 4y ago

I've been using D for OS development and have found it very good for controlling low-level details. GDC is the GCC frontend for D, and has most/all of the same features for controlling this stuff as GCC. For example, you can use `@register("edx") ulong x;` to specify that a variable should be in a particular register, `@section("t1")` on functions to place them in certain sections, and the inline assembler is the same as with GCC. Note: the @register feature is new with GDC 13. See here for the docs: https://gcc.gnu.org/onlinedocs/gdc/ https://gcc.gnu.org/onlinedocs/gdc/. And of course LDC supports all the LLVM custom attributes, plus GCC-compatible inline assembler (not sure about the "g" constraint though) and LLVM-style inline assembler.

sparkie 4y ago
Thanks for the information. Appears that it does support the section attribute from GCC too. I'll have to explore this a bit and see if I can use it, since it seems to have all or most the features I use. I did learn D some years ago when the standard library situation was not great, but might be worth looking at again.
- zyedidia 4y ago
  Depending on how much language support you want, you may want to compile without the D runtime (in which case you only have access to the C standard library, and various features are disabled, such as classes/interfaces, garbage collection, exceptions, and most of the D standard library). You can disable the D runtime in GDC with -fno-druntime and in LDC with -betterC. With those flags, the basic hello world program looks like this: import core.stdc.stdio; extern (C) void main() { printf("Hello world\n"); }

WalterBright 4y ago

The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are needed for special purposes. Gcc may be the most suitable language if you need those extensions. What I would do is use gcc for the parts of the code that need those extensions, and D for the rest (D code can directly interact with C code).

sparkie 4y ago
Thanks. My root comment mentioned that it was not really the features of C that I depended on, but the GCC specific features. I'm interested in using D now as sibling comment mentions that I can use some of these features in gcd, but I'm not yet sure how much benefit I'd get over using C by using a subset of the D features which are compatible with the constraints of my VM.
- WalterBright 4y ago
  One big feature is D has modules. There's no reason C can't have modules, but they don't. You don't need to code .h files anymore.
mhh__ 3y ago
LDC and GDC both have the section concept exposed as a UDA.
- WalterBright 3y ago
  Good!

srcreigh 4y ago

GNU jitter right? I’ve seen (a few?) highly detailed slide decks about it. Extremely cool stuff I found this pdf but I thought there was a different one, anyone link to that? https://binary-tools.net/jitter-binary-tools-summit.pdf https://binary-tools.net/jitter-binary-tools-summit.pdf

sparkie 4y ago
Not jitter, but I'm familiar with it and have used some of its ideas. (More Jitter slides referenced on Luca Saiu's page:https://ageinghacker.net/talks/#jitter-talks https://ageinghacker.net/talks/#jitter-talks) The (experimental) VM I'm working on embeds type information into pointers. I place some functions at fixed virtual addresses and use the type information from the pointer to materialize these addresses at runtime, without having to dereference any pointers until I actually call the function. Essentially, if you have a pointer you will know the type of value it points to from the pointer itself. This method places some tight constraints on how memory can be allocated, but I don't think it will be too much of a limitation for most applications intended to run on it. I have 12-bits in a 48-pointer which provide type information, which leaves a maximum 36-bits of virtual address space per type (or 35 bits if you discount the most significant bit which refers to kernel space). I'm currently using the section attribute to implement it, but I'm aware there are other methods to achieve this. I could do it at runtime by `mmap`ing the virtual memory and then loading in the machine code at the addresses I need. This method might be more flexible in the long run and would free me up from using GCC specific attributes.

GoblinSlayer 3y ago

Linux is reportedly written in C and it still has a good share of plain assembler.