Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

51–60 of 225 posts

Re: Two types of C programmers

#51

Post by sparkie »

WalterBright wrote: post #43
sparkie wrote: post #5

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top…

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

"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.

Re: Two types of C programmers

#52

Post by zyedidia »

sparkie wrote: post #51
WalterBright wrote: post #43

Earlier quoted context omitted.

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

"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 under…

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/.

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.

Re: Two types of C programmers

#53

Post by zokier »

matheusmoreira wrote: post #45
efficax wrote: post #9

Earlier quoted context omitted.

the simplicity of c is an illusion the moment you start using pointers and define macros. nothing is harder to understand than a big C program, imo

I don't see how simplicity is lost through use of pointers. Dynamic language variable references are essentially pointers and they couldn't be simpler.

Pointer provenance.

Re: Two types of C programmers

#54

Post by sparkie »

zyedidia wrote: post #52
sparkie wrote: post #51

Earlier quoted context omitted.

"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 under…

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 sam…

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.

Re: Two types of C programmers

#55

Post by WalterBright »

sparkie wrote: post #51
WalterBright wrote: post #43

Earlier quoted context omitted.

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

"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 under…

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).

Re: Two types of C programmers

#56

Post by sparkie »

WalterBright wrote: post #55
sparkie wrote: post #51

Earlier quoted context omitted.

"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 under…

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…

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.

Re: Two types of C programmers

#57

Post by jwandborg »

version_five wrote: post #17
jwandborg wrote: post #10

Earlier quoted context omitted.

10 in binary _is_ 2 in decimal. I think you've made an off-by-one error in your critique.

But it's (decimal) 3 in ternary, I think that's the point (you get a 3rd group of people if you're mistaken about the base)

Could be that I missed the joke.

Re: Two types of C programmers

#58

Post by humanrebar »

sparkie wrote: post #5

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top…

> Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++.

To be fair to C++, all the other languages in this space are as bad at providing ABIs in their own languages. All (almost?) mostly provide ways to declare C ABIs, which C++ also supports.

C++ has rough C++ ABIs, but mostly because it bothers to try in the first place. It's not like other languages really "solved" ABI better than C++ has.

Even C ABIs are a little rough since there's so much preprocessor use to factor in and/or avoid.

Re: Two types of C programmers

#59

Post by srcreigh »

sparkie wrote: post #51
WalterBright wrote: post #43

Earlier quoted context omitted.

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

"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 under…

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

Re: Two types of C programmers

#60

Post by the__alchemist »

Implicit in the article is that there are only a handful of languages capable of certain use cases. Eg, embedded, bare-metal, programming operating systems, performance-sensitive code etc. So, your options are limited (C, C++, Rust, Zig, ADA, maybe a few more?), which would drive option 2.
Post reply on HN