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

Low-Level C Programming – CSE 325 Lecture Videos

youtube.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Low-Level C Programming – CSE 325 Lecture Videos

#21

Post by userbinator »

svorakang wrote: post #10
jmole wrote: post #6

Earlier quoted context omitted.

There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem. There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usu…

Automotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability. For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture…

My favorite example is the compiler for a really strange architecture where everything is 24 bits

DSP? That's the one example I can think of where 24-bit architectures are in active use (and many of them are not Von Neumann, but Harvard with separate data/program memory.)

Re: Low-Level C Programming – CSE 325 Lecture Videos

#22

Post by userbinator »

pclmulqdq wrote: post #17
detaro wrote: post #15

Earlier quoted context omitted.

> I thought char was required by the C standard to be 8 bits It's not. (EDIT: it is required to be at least 8 bits though)

Welcome to C! The guns are free, but you can only point them at your foot. The C standard specifies so much less than everyone thinks.

It specifies so much less, precisely to allow it to be usable on such weird architectures.

Re: Low-Level C Programming – CSE 325 Lecture Videos

#24

Post by chii »

svorakang wrote: post #10
jmole wrote: post #6

Earlier quoted context omitted.

There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem. There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usu…

Automotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability. For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture…

> The reason is as the grandparent post points out: compiler availability.

is there no appetite to self-write a compiler for the architecture being used?

Re: Low-Level C Programming – CSE 325 Lecture Videos

#25

Post by detaro »

pclmulqdq wrote: post #17
detaro wrote: post #15

Earlier quoted context omitted.

> I thought char was required by the C standard to be 8 bits It's not. (EDIT: it is required to be at least 8 bits though)

Welcome to C! The guns are free, but you can only point them at your foot. The C standard specifies so much less than everyone thinks.

I wouldn't really qualify this as a foot gun, but rather appropriate flexibility. 98% of people never encounter it, and the 2% that do are happy that it is that way, and I don't think alternative approaches like having the compiler hide it are appropriate for C.

Re: Low-Level C Programming – CSE 325 Lecture Videos

#26

Post by mananaysiempre »

pclmulqdq wrote: post #18
bsder wrote: post #16

Earlier quoted context omitted.

The real reason to use C over C++ is that when you can't use heap allocated memory, you can't use 90+% of C++. At that point, you've inflicted upon yourself all the C++ footguns and have thrown away any of the C++ useful bits. Once that happens, you might as well just use C.

I disagree with you here. Off the top of my head, these are the things I like about embedded C++ (and embedded Rust): * RAII makes modern C++ a lot cleaner for things like holding locks, disabling interrupts, and other stuff that needs to be unwound at function exit, and doesn't need heap allocation. Until C gets 'defer', the cleanest alternative is gotos. * Operator overloading is pretty nice for code where you have…

Having just written a truly repulsive preprocessor hack, I’m currently in my “maybe C++’s monster of a semantics is not that bad actually” phase (it is that bad though, so that’ll pass). C’s metaprogramming facilities are severely lacking. And yet—

> Until C gets 'defer', the cleanest alternative is gotos.

In an embedded setting, a given project is probably only ever targeting a single compiler, and given that in non-exotic situations it’s a vendor fork of GCC, you should be fine using GCC-specific features. And __attribute__((cleanup)) (essentially a block-scoped defer with cleanup code exiled to a separate function) has been in GCC since (checks docs) version 3.3, from 2003. It would have to be a truly spectacular vendor GCC fork to be missing that feature. (For reference, the year 2003 also saw the release of Linux kernel 2.6, as in two-six-zero.)

Re: Low-Level C Programming – CSE 325 Lecture Videos

#27

Post by kjs3 »

detaro wrote: post #15
l33t233372 wrote: post #14

Earlier quoted context omitted.

> Char is short is long is a pointer. I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?

> I thought char was required by the C standard to be 8 bits It's not. (EDIT: it is required to be at least 8 bits though)

I thought char was required by the C standard to be 8 bits

Common misconception.

to be at least 8 bits though

At least 8 bits for the latter-day compilers for which the 'standard' was the guide. I have seen C compilers where char was 6-bit or 7-bits matching the underlying hardware. However, those probably never implemented more than K&R or some pre-standardization perversion of it.

Also...as noted a char can be more than 8 bits, pre- and post-standardization. I've heard tell of (at least) 9-, 16-, 24- and 32-bit chars on more or less weird platforms.

At some point I'm sure the standards bodies will do some variation of depreciating 8-ish-bit char's for 32-bit Unicode as the standard representation for text.

Post reply on HN