Live data from Hacker News

Thor – A minimalistic operating system in assembly and C++

github.com

81–90 of 152 posts

Re: Thor – A minimalistic operating system in assembly and C++

#81

Earlier quoted context omitted.

> Considering that the linux kernel is strongly tied to the specific C dialect supported by GCC and is not portable at all, this argument is bullshit. Linux has been ported to over two dozen architectures so it is extremely portable. Yes, it is tied to some GCC behaviors, but many operating systems are tied to compilers. Some extensions make the code identical across different archs, like __builtin_return_address. Wi…

The context of course was portability to different compilers, not architectures.

[deleted]

Re: Thor – A minimalistic operating system in assembly and C++

#82

Earlier quoted context omitted.

> Considering that the linux kernel is strongly tied to the specific C dialect supported by GCC and is not portable at all, this argument is bullshit. Linux has been ported to over two dozen architectures so it is extremely portable. Yes, it is tied to some GCC behaviors, but many operating systems are tied to compilers. Some extensions make the code identical across different archs, like __builtin_return_address. Wi…

The context of course was portability to different compilers, not architectures.

Oh gotcha... I interpreted Linus's comment about archs. Boost is supported on far less archs than the Linux kernel is:

http://www.boost.org/doc/libs/master/libs/context/doc/html/c...

Re: Thor – A minimalistic operating system in assembly and C++

#83

Earlier quoted context omitted.

Haha, I was just about to reply to your comment with nearly the same thing! I think one day I may need to do a book on C++ for embedded folks. Chapter 1 will be "Please don't use std::string!".

Could hold true to the HLL guys as well. I seem to remember at least a couple of performance analyses of apps in a High-Level Language where string concatenation was killing performance. Easy to do. Tough to always remember the impact of what's going on under the hood.

HLL's (at least those which have a VM) often try interesting techniques to combat this, since string handling is so often a performance problem (it's a performance problem because they often make it relatively painless to manipulate strings, at least to the point where it's not obvious you may be doing something really inefficient). It's interesting if you follow the development of a language while it's being developed, you can usually see a few of the techniques they've used come and go. Starting with simple string handling, then global shared copy-on-write strings, then ropes, possibly a fourth weird representation, and likely back to one of the prior, simpler models.

At least, that's what I hazily recall from the long, jumbled Perl 6 history, but that includes a few changes to the language and multiple VM's and multiple string handling regimes per VM, sometimes.

Re: Thor – A minimalistic operating system in assembly and C++

#84
post #10
post #6

Earlier quoted context omitted.

It's a really annoying widespread opinion. I've been looking for people who really do write OSes in modern C++.

IncludeOS? [0] From the CppCon 2016 presentation description: "Early in the design process we made a hard choice; no C interfaces and no blocking POSIX calls. We’ve done everything from scratch with modern C++ 11/14 - Including device drivers and the complete network stack all the way through ethernet, IP and ARP, up to and including UDP, TCP and recently also an http / REST API framework. To achieve maximum efficien…

Is that really a "hard" choice? Aren't blocking POSIX calls usually just a case where the kernel blocks for you on what is essentially an asynchronous operation anyway?

Maybe it's meant to be hard in the "we decided we weren't going to be POSIX compliant which has implications" send and not the hard to implement sense?

Re: Thor – A minimalistic operating system in assembly and C++

#86
post #45
post #6

Earlier quoted context omitted.

It's a really annoying widespread opinion. I've been looking for people who really do write OSes in modern C++.

BeOS, Symbian, L4, Genode, Mac OS X drivers, and big parts of Windows are all examples of C++ use in OS development.

And there was Chorus back in the 90's.

Re: Thor – A minimalistic operating system in assembly and C++

#87
post #79

Earlier quoted context omitted.

'It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C' Solid argument that. His two other arguments: - infinite amounts of pain when they don't work (and anybody who tel…

>>Sorry, but I take it personally when me and my colleagues are called substandard programmers. I don't know what kind of programming you do, but he is talking mainly about kernel programming. He is mainly criticizing the people who want to bring C++ in the kernel world. Anyone is welcome to prove him wrong. But I think, C++ is more suited for applications programming, where efficiency is not a prime concern and abst…

>I don't know what kind of programming you do, but he is talking mainly about kernel programming.

This specific rant was about using C++ in git. BTW I work in what could be called soft realtime systems.

> But I think, C++ is more suited for applications programming, where efficiency is not a prime concern and abstraction-costs are justified.

If efficiency is not a prime concern, using C++ is hardly justified.

> [...] the point you seem to be missing is that C doesn't force any abstractions on you.

Nor does C++.

edit:

> Even in such cases, (e.g. git, which is an application program) an excellent programmer like Linus can be very well productive with C and does not need the (sloppy/non-sloppy) abstractions provided by C++.

and that's perfectly fine, if one feels more productive in a certain language, more power to him, but please let's not spread FUD.

Re: Thor – A minimalistic operating system in assembly and C++

#88

Earlier quoted context omitted.

> If yes, why people still even think about doing it with unsafe languages? What you need for OS or embedded development is a language that doesn't get in your way. C doesn't get in your way. C is the first language that both stayed out of your way and also provided reasonable productivity features (over BCPL, B, and assembly). It was only recently that people have figured out how to come close to a "safe" language t…

Funny you should mention the Cortex-M :) https://github.com/helena-project/tock/ (written in Rust, just linked to it down thread as well)

I will check that out.

Re: Thor – A minimalistic operating system in assembly and C++

#89

Earlier quoted context omitted.

Totally agreed with your comment until that: > as long as you have a disciplined team and sane coding guidelines Is it not possible at all anymore to just hire people actually understanding what they are doing? Or cargo cult is here to stay? I am sorry - please don't take that as a personal attack, but explaining people that C++ can actually be used in OS development by mindlessly sticking to some rules doesn't seem…

It's more that certain features can be way more expensive than they look. e.g. say you're working on an embedded system, and you want a string, so you do: std::string s = "fnord"; At first it seems to work fine --- but you firmware image's RAM requirements have just gone up by 32kB, and a week later there's a crisis when adding another feature causes the system to stop linking because the RAM address space is full. W…

In your string example (and in RTOS/C++ programming in general) couldn't you just change the default allocator to not use heap memory ? Then continue using std::whatever ? of course you'd have to keep a very close eye on your memory pool, but wouldn't this be one way to solve the problem ?

Re: Thor – A minimalistic operating system in assembly and C++

#90
post #55

Earlier quoted context omitted.

The OSDev wiki is the best think to hit the internet since sliced bread (with cats faces pushed through them?) but it's far from a tutorial. It's a wiki. While it is one of the best repositories of knowledge on the subject of low level development, it's not a step by step guide. In the same way I don't recommend that people read Wikipedia to learn about human history I'd also not recommend reading osdev to learn abou…

What would be a good step-by-step tutorial in your opinion?

If you'd like the links that really helped me, check out this:

http://www.osdever.net/bkerndev/Docs/title.htm

http://www.brokenthorn.com/Resources/OSDevIndex.html

https://github.com/stephenfewer/NoNameOS

https://anastas.io/osdev/memory/2016/08/08/page-frame-alloca...

https://github.com/kjiwa/x86-boot-sector-c

These are all useful. If you're more of a book worm check out Minix as said in other parts of this tree. Very very easy to read, interesting bits of history about OS development, and source code included! Nothing's useful without source code.

If you'd like to look up some general software books check out Programming the IBM PC, or something to that effect. It's commonly called The Pink Shirt Book. Has interesting stuff on IBM interrupts, coding standards, and bits on filesystems!

Post reply on HN