News for hackers. Stuff that matters.
Re:On the history and justification of the C programming lan... by nickpsecurity on Thursday August 18, 2016 @08:29PM (#12317225)
"And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?"

The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few:

http://www.astrobe.com/Oberon.htm

http://www.mikroe.com/mikropascal/#

http://www.mikroe.com/mikrobasic/

Re:On the history and justification of the C programming lan... by ArkyBeagle on Friday August 19, 2016 @01:45PM (#12321875)
Why is it we're not all using Oberon again? :) Ah, I remember having meetings about things like that... now that was inertia.

SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down.

I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible.

And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.