EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: DiTBho on January 11, 2021, 09:29:11 pm
-
I am learning Rust step by step, and I wonder if at the end of the course I will be ever able to write something like a mini scheduler that can run on a real target.
I am learning Rust step by step, and I wonder if at the end of the course I will be ever able to write something like a mini scheduler that can run on a real target.
Probably no, but hey? At least I will have learned something new :D
The same applied to other languages I have learned in the past. For instance ... Pascal? I have never seen an OS written in such language. Basic? No nice, etc.
Except Assembly. I have seen a lot of firmware and operating systems written in Assembly, but all my books about operating systems mention C or C++ as the only development language.
Have anyone seen and can report here a link to an OS not written in C/C++/ObjC?
-
TempleOS (https://en.wikipedia.org/wiki/TempleOS), obviously (HolyC (https://github.com/jamesalbert/HolyC-for-Linux) and x86 assembly).
Many less famous operating systems such as Linux and Windows follow this pattern, though they tend to use boring mainstream languages like C and C++.
OS/360 (https://en.wikipedia.org/wiki/OS/360_and_successors) was written in pure assembly, because in those days, men were real men (https://www.cs.utah.edu/~elb/folklore/mel.html).
-
I think a large chunk of the first Mac OS versions was written in Pascal. Ditto for Lisa OS which Mac OS was partly based on.
CP/M was partly written in PL/M.
Probably a lot of other examples, that's the two that come to mind at the moment.
Edit: I should also have mentioned Wirth's Oberon OS, written in Oberon! Although mostly an academic exercise and learning tool, it was a usable OS.
-
http://menuetos.net/ (http://menuetos.net/) - Pure Assembly
One can't write an OS in garbage collected languages, maybe some kind of student didactic implementation running on a virtual machine, you get rid of C/C++ and assembly, no OS, end of story.
Maybe sometimes later when the access to the actual hardware will restricted and just be offered via some hypervisor or other virtualization/containerization/obfuscation/simulation system one can make a "safe & modern" >:D OS in Python, node.js, Ruby, Rust, Go or other crap application languages, but the real OS glued to the HW will still be C/assembly. Other 65535 attempts failed miserably so far, you can't write OS low level stuff with import system.os.
Of course all the other stuff above could still be used perfectly fine for writing apps and other user mode programs, just not bootloaders, drivers and schedulers. Who isn't able to cut it in assembly and C should stay away from any OS related stuff.
Cheers,
DC1MC
-
thanks guy!
any publicly available source? ;D
-
http://menuetos.net/ (http://menuetos.net/) - Pure Assembly
Wow, crazy, but cool :D
Who isn't able to cut it in assembly and C should stay away from any OS related stuff.
Umm, not exactly related to your sentence, but it made me thing these two lines are sometimes mixed up.
For instance I don't want to have anything to deal with the Linux kernel, and I develop a lot of applications and libraries in user-space, but with FreeRTOS it's a completely different approach, and I like to play with its kernel stuff.
Also the kind of target makes the difference. For instance I don't like to have anything to deal with the low-level of a PowerPC e5xx because its user-manual is more 600 pages, the architecture itself is very complex (especially with super-scalar with tons of cops around) and my memory is so limited that I do find the whole experience far from being pleasant, but I like to play with a simple Arm classic even in assembly because it's simpler and its datasheet shorter, both of several orders of magnitude :D
-
Very few OSes have been written in C or C++, but most of the ones which have survived until now are. There were a lot of OSes developed before C existed, and a lot more were developed before C++ existed.
-
any publicly available source? ;D
I was looking for early Mac OS source code, but haven't found anything. I don't think Apple ever released it, does anyone know? That would be fun to look at.
For CP/M, here it is: http://www.cpm.z80.de/source.html (http://www.cpm.z80.de/source.html)
Oberon: http://www.projectoberon.com/ (http://www.projectoberon.com/)
-
I started to see many project of writing OS in Rust recently.
The list of some of them.
https://github.com/flosse/rust-os-comparison
-
This is, by no means, an exhaustive list; just a few systems off the top of my head.
Commercial systems that I've actually worked on that the OS was programmed in a high level language that wasn't C, and weren't assembly based:
Multics - PL/1 - https://en.wikipedia.org/wiki/Multics (https://en.wikipedia.org/wiki/Multics)
MCP - various proprietary Algol variants - https://en.wikipedia.org/wiki/Burroughs_MCP (https://en.wikipedia.org/wiki/Burroughs_MCP)
CTOS - PL/M - https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_System (https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_System)
TOPS-10 - BLISS - https://en.wikipedia.org/wiki/TOPS-10 (https://en.wikipedia.org/wiki/TOPS-10)
PERQ - Pascal - https://en.wikipedia.org/wiki/PERQ (https://en.wikipedia.org/wiki/PERQ)
PR1MOS - PL/P, SPL both proprietary PL/1 variants - https://en.wikipedia.org/wiki/PRIMOS (https://en.wikipedia.org/wiki/PRIMOS)
Ericsson AXE (et. al) OS (telephone switch/exchange) - PLEX/SDL
Nortel DMS-100 telephone switch OS - PROTEL - https://en.wikipedia.org/wiki/Protel (https://en.wikipedia.org/wiki/Protel)
Commercial systems that I've no personal direct experience of:
ICL VME 2900 - S3 a proprietary Algol 68 variant - https://en.wikipedia.org/wiki/ICL_VME (https://en.wikipedia.org/wiki/ICL_VME)
Xerox Star - MESA
IBM System/38 - PL/S another PL/1 variant
Research/Educational systems:
Cambridge CAP - Algol68
CTSS (MIT) - MAD an Algol variant
-
Lisp machines - a company that temporarily flourished during the first A.I. boom in the mid 80's had their own hardware and most of it including most of the OS was written in Lisp.
This then brings you to the point where you need to decide how much of the coding you want to be in the high(er) level language. You will need some assembly regardless, just to diddle the registers in an intimate fashion.
-
OpenFirmware was written in Forth.
-
TOPS-10 - BLISS - https://en.wikipedia.org/wiki/TOPS-10 (https://en.wikipedia.org/wiki/TOPS-10)
VMS might be a more interesting example from DEC. It started out mostly in BLISS, and migrated to C over time, with a few big step changes in the C content. Interestingly, BLISS continued for so long that after Compaq bought DEC they produced a BLISS compiler for IA64. This seems to indicate that they never got VMS entirely free of BLISS code.
-
I think a large chunk of the first Mac OS versions was written in Pascal. Ditto for Lisa OS which Mac OS was partly based on.
That's my, rather vague and dim, recollection too.
TRIPOS (https://en.wikipedia.org/wiki/TRIPOS) was largely written in BCPL with a small bit of assembler in the kernel. Despite what that Wikipedia article says, device drivers were written in BCPL (all the ones I worked on were at least). Although, since BCPL is a predecessor of C it might not count.
@DC1MC
One of the big selling points of Rust is that it is useable for the sort of low level systems programming that C and C++ are used for.
-
The Xerox Star (and Dandelion etc) were all built up using MESA. (I think the Alto started up BCPL and then MESA?)
I forget the names... The OS was Pilot? CoPilot? later Viewpoint?
The hardware "Wildflower architecture" was micro-coded to be MESA friendly.
MESA was a nice language and had much in common with the language I used for my 3rd year project... Concurrent CLU.
Wow that was a long long time ago. :)
-
I think a large chunk of the first Mac OS versions was written in Pascal. Ditto for Lisa OS which Mac OS was partly based on.
That's my, rather vague and dim, recollection too.
Yep. I had a Mac in the early nineties, and remember I had a few "Inside Macintosh" books (is there anyone else here who did?), each dealing with a particular part of the Mac OS API. All interfaces were described in Pascal AFAIR.
In 2017, it was announced that the Lisa OS would be released as open source in 2018.
https://fossbytes.com/apples-lisa-operating-system-free-open-source-release/
But AFAIK, it never did. Does anyone know what happened?
Now regarding C... please correct me if I'm wrong, but I think C was actually not that popular outside of the Unix world in the 80's. I think it really started to get momentum in the late 80's to early 90's. So I don't think there actually were many OS's written in C back then, except again from Unix and derivatives.
-
One of the big selling points of Rust is that it is useable for the sort of low level systems programming that C and C++ are used for.
That's why I have invested money and I am investing time to learn it :D
-
MESA was a nice language and had much in common with the language I used for my 3rd year project... Concurrent CLU.
Oh, yeah! You'll find the ref manual here: http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf (http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf)
-
Now regarding C... please correct me if I'm wrong, but I think C was actually not that popular outside of the Unix world in the 80's.
By the early 80s C was a big deal all over the computing world.
-
There were not many OSes written in C + assembly, only the ones who actually matter and passed the test of time, the rest went as academic masturbation, hyper-specialized NIH stuff and forgotten attempts of enthusiasts, forever remaining at version 0.0.1alpha0 in a forgotten '90s stile web page or repository.
Rust will go like all the rest of over-engineered cretinic experiments, only to be eventually used in some kind of hypervisor or virtualization, where the heavy lifting will be done by C or assembly stuff, but it will be not visible to the mediocre programmer who will happily announce that "duuude, I've written a user mode driver in Python... Yeah dude, I written a scheduler in Rust, this OS stuff is so simple...".
Some times low level and difficulty is just that, not reducible to application level stuff and trying to sugarcoat it with automated garbage collectors and object paradigms, glorified interpreters of pseudocode and other crutches for mediocre programmers will always fail.
-
The Oberon system was written in Oberon - though more of an academic system (at ETH).
AFAIK there was also a simile system in Modula.
Most OS need at least some parts in ASM too. This may not be directly visible but as startup / library code for the compiler. Some of the really low level parts are too low even for C.
AFAIK the Apple Lisa system was written in Pascal. For better performance and less space needed much of this was rewritten / optimized in ASM for the early MAC OS.
-
There were not many OSes written in C + assembly, only the ones who actually matter and passed the test of time, the rest went as academic masturbation, hyper-specialized NIH stuff and forgotten attempts of enthusiasts, forever remaining at version 0.0.1alpha0 in a forgotten '90s stile web page or repository.
Rust will go like all the rest of over-engineered cretinic experiments, only to be eventually used in some kind of hypervisor or virtualization, where the heavy lifting will be done by C or assembly stuff, but it will be not visible to the mediocre programmer who will happily announce that "duuude, I've written a user mode driver in Python... Yeah dude, I written a scheduler in Rust, this OS stuff is so simple...".
Some times low level and difficulty is just that, not reducible to application level stuff and trying to sugarcoat it with automated garbage collectors and object paradigms, glorified interpreters of pseudocode and other crutches for mediocre programmers will always fail.
Do you know anything at all about Rust or are you just blathering on ignorantly and arrogantly like a senile old man? It is not garbage collected. It was specifically designed for systems programming. It does not need a hypervisor or virtual machine, and its capabilities are very analogous to those of C or C++. It performs better than C/C++ on most microbenchmarks. And it has a lot fewer gotchas that trap even the best programmers from time to time, often leading to major security holes.
-
Do you know anything at all about Rust or are you just blathering on ignorantly and arrogantly like a senile old man?
Are you blathering on ignorantly and arrogantly like a young idiot without the experience of seeing endless repeating cycles of the Next Big Thing that fades away? There's always that one wonderful little thing they do, that means the world is going to see the brilliance of the Next Big Thing and flock to it. Every once in a long while people actually do. Not often, though. Maybe Rust will hit the big time, but the odds are heavily against it unless one or more massive long term systems that are needed all over the place are written in it.
-
There were not many OSes written in C + assembly, only the ones who actually matter and passed the test of time, the rest went as academic masturbation, hyper-specialized NIH stuff and forgotten attempts of enthusiasts, forever remaining at version 0.0.1alpha0 in a forgotten '90s stile web page or repository.
Rust will go like all the rest of over-engineered cretinic experiments, only to be eventually used in some kind of hypervisor or virtualization, where the heavy lifting will be done by C or assembly stuff, but it will be not visible to the mediocre programmer who will happily announce that "duuude, I've written a user mode driver in Python... Yeah dude, I written a scheduler in Rust, this OS stuff is so simple...".
Some times low level and difficulty is just that, not reducible to application level stuff and trying to sugarcoat it with automated garbage collectors and object paradigms, glorified interpreters of pseudocode and other crutches for mediocre programmers will always fail.
Try and get a grip on that C Programming Language fanboyism ?
The first versions of rustc (before 1.0) were written in OCaml, and then rewritten in rust itself.
-
Are you blathering on ignorantly and arrogantly like a young idiot without the experience of seeing endless repeating cycles of the Next Big Thing that fades away? There's always that one wonderful little thing they do, that means the world is going to see the brilliance of the Next Big Thing and flock to it. Every once in a long while people actually do. Not often, though. Maybe Rust will hit the big time, but the odds are heavily against it unless one or more massive long term systems that are needed all over the place are written in it.
Whilst Rust certainly has a big hill to climb in order to avoid being just another Next Big Thing C/C++ killer that fades away, it does have the advantage that it can actually be used for all the things C/C++ can. It also seems to be getting traction in Linux - Rust code in Linux kernel looks more likely as language team lead promises support (https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/).
-
OCaml
Do you think it is also worth to learn this language in 2021?
I am so tempted, although at the moment my priority is Rust.
I enjoyed the above post with a link to an real OS written in Rust!
I am the kind of person who better learns by examples :D
-
OCaml
Do you think it is also worth to learn this language in 2021?
Learning something new is almost always worth it.
Now whether you will personally ever use OCaml for anything useful is another question.
-
Do you know anything at all about Rust or are you just blathering on ignorantly and arrogantly like a senile old man?
Are you blathering on ignorantly and arrogantly like a young idiot without the experience of seeing endless repeating cycles of the Next Big Thing that fades away? There's always that one wonderful little thing they do, that means the world is going to see the brilliance of the Next Big Thing and flock to it. Every once in a long while people actually do. Not often, though. Maybe Rust will hit the big time, but the odds are heavily against it unless one or more massive long term systems that are needed all over the place are written in it.
I did not argue it would be successful, just that 90% of the blathering I quoted does not apply to Rust and belies a complete lack of understanding of the actual situation. I also think the attitude that good programmers don't make mistakes and therefore don't need tools that make doing things correctly easier is elitist and stupid. Like anyone enjoys malloc/free, or is infallible at it :palm:.
Will it succeed? Yet to be seen. Does it have even one of the shortcomings that DC1MC rants about? No. Would the success of a modern language capable of systems programming be a good thing? Undeniably yes.
-
One can't write an OS in garbage collected languages
That isn't even remotely true. Just like with all languages, when writing an OS you may need to implement some parts of the runtime yourself. When writing an OS in C, you either have to avoid malloc entirely, implement it yourself, or use a library implementation that provides low level hooks to manipulate memory pools. The same is true with garbage collection -- garbage collectors need some underlying functions to manage the size of their memory pools, but if you provide those you could absolutely use GC in an OS.
-
I would say, let's tune it down with name calling and person attacks, call names the tools (even the concepts), not the people. Insulting the discussion partners does not anyones point stronger and does not make one seem smarter, au contraire.
This being said, I will leave this topic forever and let you in the capable hands of the soon to be cRUSTaceeans overlords.
DC1MC
-
OCaml
Do you think it is also worth to learn this language in 2021?
I am so tempted, although at the moment my priority is Rust.
I enjoyed the above post with a link to an real OS written in Rust!
I am the kind of person who better learns by examples :D
I think its a language you might want to learn, not so much to be able to use it but to see a rather different take on computer languages. There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol :)
-
I would say, let's tune it down with name calling and person attacks, call names the tools (even the concepts), not the people. Insulting the discussion partners does not anyones point stronger and does not make one seem smarter, au contraire.
This being said, I will leave this topic forever and let you in the capable hands of the soon to be cRUSTaceeans overlords.
DC1MC
You started off by insulting a whole class of people, so I don't think it very appropriate of you to lay claim to the moral high ground.
There were not many OSes written in C + assembly, only the ones who actually matter and passed the test of time, the rest went as academic masturbation, hyper-specialized NIH stuff and forgotten attempts of enthusiasts, forever remaining at version 0.0.1alpha0 in a forgotten '90s stile web page or repository.
Rust will go like all the rest of over-engineered cretinic experiments, only to be eventually used in some kind of hypervisor or virtualization, where the heavy lifting will be done by C or assembly stuff, but it will be not visible to the mediocre programmer who will happily announce that "duuude, I've written a user mode driver in Python... Yeah dude, I written a scheduler in Rust, this OS stuff is so simple...".
Some times low level and difficulty is just that, not reducible to application level stuff and trying to sugarcoat it with automated garbage collectors and object paradigms, glorified interpreters of pseudocode and other crutches for mediocre programmers will always fail.
-
... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol :)
But Lisp may be taking things too far. :)
-
... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol :)
But Lisp may be taking things too far. :)
Well, I'd list LISP as one of the interesting things to learn, but I'd put it in brackets.
-
... There are a few languages its worth learning just to broaden your understanding of what a computer language can be like. Everyone should learn Snobol :)
But Lisp may be taking things too far. :)
Well, I'd list LISP as one of the interesting things to learn, but I'd put it in brackets.
(why (would (you (say that))))
-
It also seems to be getting traction in Linux - Rust code in Linux kernel looks more likely as language team lead promises support (https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/).
The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers :-DD
OCaml
Do you think it is also worth to learn this language in 2021?
Not necessarily, it will also be okay if you learn Standard ML instead.
-
It also seems to be getting traction in Linux - Rust code in Linux kernel looks more likely as language team lead promises support (https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/).
The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers :-DD
Well, Linux talking about Rust seems to have be blown out of proportion. At no point I understand that Linus is going to consider replacing C with Rust for the Linux kernel, neither tomorrow nor maybe even in 10 years. All we can conclude, for what he said, I guess, is that at least he doesn't reject it violently as he has always done with C++.
-
IMO moving everything to a different language is simply not gonna happen within the lifetimes of the project, but even accepting individual modules I think would be unlikely. But hey, you can always compile something yourself and modprobe it ;) Some guys at some Polish university even put Haskell in there, whatever floats your boat.
-
The Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developers :-DD
LOL ;D
well .. true, but Linus is somehow using C as object programming language done with a language that does not have any native support for this; C++ does have, but Linus doesn't like it, Rust does have, and Linus is looking at it, but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.
Anyway, for me, fastly evolving means that even Rust is looking at Linux, in order to provide what is really needed.
-
Have anyone seen and can report here a link to an OS not written in C/C++/ObjC?
You can find Forth OS written in almost every language there is including Rust, LISP, Assembly, BASH, Perl, Lua, Python, C, C++, etc. The Forth I use (below in my sig) is written in assembler.
Just a few examples:
Staapl is a macro assembler on steroids for PIC18F microcontrollers. It can be used for writing firmware optimized for size. It goes where C can’t go, and where assembler would be too complicated. It is based on Racket Scheme (code generator) and Forth (low-level language and machine model).
http://zwizwa.be/staapl (http://zwizwa.be/staapl)
rust-forth-compiler 0.5.3
https://docs.rs/crate/rust-forth-compiler/0.5.3 (https://docs.rs/crate/rust-forth-compiler/0.5.3)
Firth, A simple Forth-like language intended for DSL creation, implemented in Lua.
https://github.com/IonoclastBrigham/firth (https://github.com/IonoclastBrigham/firth)
pyforth, A minimal implementation of the FORTH language, written in Python.
https://github.com/whaleygeek/pyforth (https://github.com/whaleygeek/pyforth)
-
https://github.com/microsoft/MS-DOS
-
Re: VMS and BLISS
My recollection was that VAX/VMS and PDP-11/RSX-11 were both written primarily in assembler. The VAX filesystem (FILES-11), however, had BLISS components at least.
I took the VAX/VMS internals courses in the 80's and wrote kernel modules for a few projects. (Digital alum 1983 - the acquisition of my division by Intel). Prior to Digital I wrote an I/O driver for RSX. I don't ever recall seeing any BLISS modules as part of the VAX VMS kernel prior to V5.0 -- perhaps BLISS was introduced after that.
BLISS-11 was used to build the StarOS operating system for CMU's Cm*.
-
but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.
This is a *major* issue indeed.
-
At no point I understand that Linus is going to consider replacing C with Rust for the Linux kernel, neither tomorrow nor maybe even in 10 years. All we can conclude, for what he said, I guess, is that at least he doesn't reject it violently as he has always done with C++.
As I understand it, the rejection is logical: Unlike C's freestanding environment (which Linux relies on), C++'s still requires a runtime for <new> and <exception>, and that makes it a no-go, because the Linux kernel would have to be fundamentally redesigned to run on such a runtime. Also, C++'s freestanding environment leaves too many things implementation defined, which means kernel developers would have to beg the compiler developers to provide sane implementation-defined behaviour, and except for the last few years, dealing with GCC developers has been quite a headache for the kernel developers.
It is important to note that most of the embedded C++ environments used with e.g. microcontrollers aren't really C++, but a subset of the freestanding C++ environment; in particular, exceptions are not supported. So, while an enthusiastic C++ programmer will just say "then only use the subset you want!", the problem is that when you have a project that potentially will live for decades, you want something to rely on, instead of relying on implementation-defined behaviour and the assumed benevolence of the compiler developers.
In comparison, freestanding C environment is simple and well defined.
I believe this also shows why developing an OS kernel requires either a strictly defined compiler, or close cooperation with compiler developers. I would be particularly interested in the interaction between Rust and Redox developers, especially since both are actively evolving. In this PC era, I suppose any truly friction-causing issues are only discussed in private, without movement-starting paper trails... I liked the honesty of LKML, where idiotic suggestions like kdbus got called out in public.
-
Re: VMS and BLISS
My recollection was that VAX/VMS and PDP-11/RSX-11 were both written primarily in assembler. The VAX filesystem (FILES-11), however, had BLISS components at least.
I took the VAX/VMS internals courses in the 80's and wrote kernel modules for a few projects. (Digital alum 1983 - the acquisition of my division by Intel). Prior to Digital I wrote an I/O driver for RSX. I don't ever recall seeing any BLISS modules as part of the VAX VMS kernel prior to V5.0 -- perhaps BLISS was introduced after that.
BLISS-11 was used to build the StarOS operating system for CMU's Cm*.
As I understanding it there may not be much BLISS in the VMS kernel itself, but a large part of the code surrounding the kernel, that makes it a complete operating system, was originally in BLISS.
-
but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.
This is a *major* issue indeed.
This was one of the major things holding C++ back in the 90s. There was a period when almost every compiler update you received broke something in your code. If not for that, C++ compilers might well have displaced C compilers, with some of us writing like we were still using C, and some of us writing with the full features of C++.
-
but the Rust language is fastly evolving, and because of this certain compatibility issues can arise, despite efforts to ensure forwards-compatibility wherever possible.
This is a *major* issue indeed.
This was one of the major things holding C++ back in the 90s. There was a period when almost every compiler update you received broke something in your code. If not for that, C++ compilers might well have displaced C compilers, with some of us writing like we were still using C, and some of us writing with the full features of C++.
Apart from specific merits, or lack thereof, of a given language, this is the most problematic point indeed.
Regarding using "subsets" of a language, which is a relatively common approach with C++, I do think this is also a problem rather than a solution, especially when such subset is NOT clearly defined, which, as I have witnessed over the years, is the usual.
SPARK, OTOH, is an example of a well-defined subset (of ADA), and as such, it's usable. But with C++, I have rarely seen, if ever, a well-defined subset, in a clear report, that developers would stick to, so even the subset is often a moving target.
-
Quote
TOPS-10 - BLISS -
https://en.wikipedia.org/wiki/TOPS-10 (https://en.wikipedia.org/wiki/TOPS-10)I'm pretty sure that TOPS-10 was written mostly in Macro-10, the PDP-10s assembly language.It's origins pre-date Bliss, and TOPS-20 (which is NEWER than TOPS10) was pretty much all Macro-10.
That's not to say that there was no Bliss involved anywhere. But ... not a lot.
(Heh. In the tops10 days, the lines between the "monitor" (OS) and utilities were pretty blurry. The user command processor was part of the monitor, for instance, but I'm not exactly where the lines in "programming language" were. In more recent times, there's a sharper line between "kernel" and "support code", but the overall term "OS" encompasses both (and generally "more" of the user-code)...)
The various "LISP machines" of the mid-1980s certainly had much of their "OS" written in LISP.
-
I think a large chunk of the first Mac OS versions was written in Pascal. Ditto for Lisa OS which Mac OS was partly based on.
Correct. The Lisa software and classic Mac OS (originally known simply as the Mac System Software) were originally written in Pascal. However, the Mac’s smaller ROM and RAM forced them to rewrite much of it in 68K assembler simply to make it fit. (In early Macs, there was about as much OS in ROM as on disk.)
From https://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt (https://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt)
The Macintosh used the same Motorola 68000 microprocessor as its predecessor, the Lisa, and we wanted to leverage as much code written for Lisa as we could. But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.
We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish.
The Mac lacked the memory mapping hardware prevalent in larger systems, so we needed a way to relocate memory in software to minimize fragmentation as blocks got allocated and freed. The Lisa word processor team had developed a memory manager with relocatable blocks, accessing memory blocks indirectly through "handles", so the blocks could be moved as necessary to reduce fragmentation. We decided to use it for the Macintosh, again by recoding it from Pascal to assembly language.
Folklore.org is a website run by Andy Hertzfeld, one of the original Mac software devs, and has lots of references to said Pascal, e.g.:
https://www.folklore.org/StoryView.py?project=Macintosh&story=3rd_Party_Developers_and_Macintosh_Development.txt (https://www.folklore.org/StoryView.py?project=Macintosh&story=3rd_Party_Developers_and_Macintosh_Development.txt)
-
In the meanwhile I wrote my driver in assembly for an ultrasonic ranger sensor used a personal soft-core for which, being its ISA a pure invention of mine, there is neither a C compiler nor a Pascal compiler, and I also had to write my own assembly compiler.
I just wrote a simple driver that samples the voltage from an SPI 12 bit ADC, controls the output trigger of the ultrasonic pulse transmitter and measure the pulse-width(1) of the echo impulses that return to the receiver, yet I am already so lost and so exhausted that I can't really understand how people have Managed these things before HL compilers :o :o :o
(1) there is a free runner 32bit timer and bit compare circuit for this, it needs to be armed and controlled.
-
One can't write an OS in garbage collected languages, maybe some kind of student didactic implementation running on a virtual machine, you get rid of C/C++ and assembly, no OS, end of story.
Not true, provided you are sufficiently imaginative and clever!
Smalltalk-80 manages that.
See, for example, Apple's original Smalltalk port of The Xerox 1.0 release. That runs on a FatMac from two floppies. It is, of course, glacially slow since it didn't have L. Peter Deutch's groundbreaking JIT. FFI http://macintoshgarden.org/apps/apple-smalltalk-80 (http://macintoshgarden.org/apps/apple-smalltalk-80)
Play with it's modern descendent Squeak, which has the interesting feature that the VM itself (including GC) is written in Smalltalk. FFI https://dl.acm.org/doi/10.1145/3281287.3281295 (https://dl.acm.org/doi/10.1145/3281287.3281295)
-
http://menuetos.net/ (http://menuetos.net/) - Pure Assembly
One can't write an OS in garbage collected languages, maybe some kind of student didactic implementation running on a virtual machine, you get rid of C/C++ and assembly, no OS, end of story.
Sorry dude:
https://en.wikipedia.org/wiki/Lisp_machine
It has been done and it worked really well.
Also JavaOS:
https://en.wikipedia.org/wiki/JavaOS
(and if you think that is something research and exotic, look up what Jazelle is - ARM CPUs had specific support for running Java bytecode natively ...)
There is nothing intrinsic about garbage collection that would prevent you from writing an OS in in a language using it. Garbage collection can be both controlled and disabled when you don't want it to interfere with important processing. Again something that has been done many times.
The same about C/C++ and assembly - the underlying hardware runs machine code and really does not care squat about how you generate it. Whether it is by manually punching cards or by some sophisticated compiler/assembler stack.
That doesn't mean you would write an OS in something like Python these days but it has nothing to do with this garbage collection urban myth.
-
I vaguely remember parts of AmigaOS were written in BCPL. C is not that old. I figure most OS before Unix were written in something else but C.
-
I vaguely remember parts of AmigaOS were written in BCPL. C is not that old. I figure most OS before Unix were written in something else but C.
OSes before Unix were written in assembly language! It was absolutely heretical to think that an OS could be written primarily in a high level language -- not to mention a portable one.
-
OSes before Unix were written in assembly language! It was absolutely heretical to think that an OS could be written primarily in a high level language -- not to mention a portable one.
That's just false.
https://en.wikipedia.org/wiki/History_of_operating_systems
Burroughs Corporation introduced the B5000 in 1961 with the MCP (Master Control Program) operating system. The B5000 was a stack machine designed to exclusively support high-level languages, with no software, not even at the lowest level of the operating system, being written directly in machine language or assembly language; the MCP was the first[citation needed] OS to be written entirely in a high-level language - ESPOL, a dialect of ALGOL 60 - although ESPOL had specialized statements for each "syllable"[NB 2] in the B5000 instruction set. MCP also introduced many other ground-breaking innovations, such as being one of[NB 3] the first commercial implementations of virtual memory. The rewrite of MCP for the B6500 is still in use today in the Unisys ClearPath/MCP line of computers.
That is an actual commercial system (thus not some boutique lab research thing of which there were plenty) and predates even development of C (Algol 60 was a major inspiration for both B, BCPL and later C), not just Unix.
Others:
- Pilot https://en.wikipedia.org/wiki/Pilot_(operating_system) (writen in Mesa)
- Forth has been (and still is) used on bare hardware as a rudimentary OS
Probably some more.
That something is prevalent doesn't mean it is the only way of doing things and that doing things in another way is impossible or hasn't been done.
-
I vaguely remember parts of AmigaOS were written in BCPL. C is not that old. I figure most OS before Unix were written in something else but C.
OSes before Unix were written in assembly language! It was absolutely heretical to think that an OS could be written primarily in a high level language -- not to mention a portable one.
*Cough* Multics. *Cough*
-
*Cough* Multics. *Cough*
Multics is not a good counter-example to his claim. Parts of it were written in PL/I but a large part was in assembly.
-
TRIPOS (https://en.wikipedia.org/wiki/TRIPOS) was largely written in BCPL with a small bit of assembler in the kernel. Despite what that Wikipedia article says, device drivers were written in BCPL (all the ones I worked on were at least). Although, since BCPL is a predecessor of C it might not count.
Early AmigaDOS was also written in BCPL, and later versions still included some remnants.
-
One can't write an OS in garbage collected languages, maybe some kind of student didactic implementation running on a virtual machine, you get rid of C/C++ and assembly, no OS, end of story.
Not true, provided you are sufficiently imaginative and clever!
Yep. Of course you can. Now whether this is a good idea is another question. Not a trivial one to answer either.
We'd first need to consider what part of the "OS" we are talking about. Kernel? Drivers? Higher-level stuff? All of this? And what kind of architecture? Monolithic? Microkernel? This may all have an impact on the applicability of garbage collection.
-
>:D >:D >:D >:D >:D >:D >:D
And in the end, all the above examples proved to be mostly of academic and research interest (even there, just briefly) and abject commercial failures, this is why they are now a footnote in OS history.
Of course, the people experimenting with this stuff in '70 had the excuse that it was not tried before, but really, "Language X" machines ?!?!
What if I want to run a "Language Y" program on the highly optimized "Language X" machine ?
Probably they're still wondering how come nobody was interested in such a perfect Lisp language optimized machine, that besides an ultra narrow application in academia, is fully useless for anything else, and believing that general purpose computers and Windows killed their proprietary abomination because of M$ monopoly :-DD, oh wait, that was way before Windows, it tells scores when bloody Unix !!! was immediately considered more user friendly and useful than their monstrosity.
I mean, because the CPU complexity becomes higher and higher, along with cheap RAM and lot of cores, it is conceivable that there will be a general purpose OS written in some higher level language in the future, other than a combination of C and assembly, to hold the hand of feeble minded incompetents, oh sorry, that sounded too harsh, to "increase security and reliability" and "reduce the development costs and time to market", but the most lame way to waste money is to produce language specific optimized CPUs and platforms, I don't see many Jazelle running CPU lately, do you ?
Cheers,
DC1MC
>:D >:D >:D >:D >:D
-
I vaguely remember parts of AmigaOS were written in BCPL.
Do you have any reference to back up that claim?
-
Amiga ROM Kernel Reference Manual series.
-
And in the end, all the above examples proved to be mostly of academic and research interest (even there, just briefly) and abject commercial failures, this is why they are now a footnote in OS historu machines
That's overstating it, of course. It.is also missing a key point: why?
The answer isn't technical merit but cost and opportunity. C and Unix were given away freely because they didn't have commercial value to AT&T.
Something similar happened with the WWW and HTML from CERN.
-
I vaguely remember parts of AmigaOS were written in BCPL.
Do you have any reference to back up that claim?
The AmigaDOS part of AmigaOS was the corresponding bits of TRIPOS, which was written in BCPL, ported to use the AmigaOS kernel. It was replaced in later versions with C code. See the Wikipedia page on AmigaOS for more details (https://en.wikipedia.org/wiki/AmigaOS#AmigaDOS).
I was a TRIPOS systems programmer in the early 1990s and using the Amiga command line was essentially the same as using a TRIPOS system.
-
What if I want to run a "Language Y" program on the highly optimized "Language X" machine ?
Nowadays the very real problem is that no architecture will ever be built unless it can run C -- even though there would be many many significant advantages if C's problems could be left in the past where they belong. C is now a major impediment to improvement just like the 80x86 ISA.
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
-
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
in my opinion, that's because in modern projects (softcore and researching) they don't have dreams, they have commercial goals ...
-
OK, it's planned for this weekend a new attempt to write a "scheduler" in assembly.
I can do it
I can do it
I can do it
Can I? :o :o :o
-
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
in my opinion, that's because in modern projects (softcore and researching) they don't have dreams, they have commercial goals ...
Which demonstrates you have zero knowledge of either. Both enable orders of magnitude improvement in different areas - that's why they are interesting.
-
>:D >:D >:D >:D >:D >:D >:D
And in the end, all the above examples proved to be mostly of academic and research interest (even there, just briefly) and abject commercial failures, this is why they are now a footnote in OS history.
You mean like that Burroughs mainframe system which is still used to this day?
Of course, the people experimenting with this stuff in '70 had the excuse that it was not tried before, but really, "Language X" machines ?!?!
What if I want to run a "Language Y" program on the highly optimized "Language X" machine ?
Then you most likely can - that an OS is written in one language doesn't automatically mean that it won't run anything else.
And moving the goalposts, aren't we?
Probably they're still wondering how come nobody was interested in such a perfect Lisp language optimized machine, that besides an ultra narrow application in academia, is fully useless for anything else,
Yeah right, that's why LispMachines Inc. and Symbolics were making such a killing in the late 70s and 80s - with graphic UIs, networking etc. when everyone else was using dumb terminals and later on 80x25 text ...
They were used for a lot of things, that they were obsoleted in the 90s and replaced by other things is normal evolution of technology (and most had zero to do with Lisp but with poor business decisions of the companies making them). SGI workstations were also the high end graphic workstation "duck's guts". You can't buy one anymore. Does that mean they were "useless for anything else too"? Probably one of your cars was designed on one.
I mean, because the CPU complexity becomes higher and higher, along with cheap RAM and lot of cores, it is conceivable that there will be a general purpose OS written in some higher level language in the future, other than a combination of C and assembly, to hold the hand of feeble minded incompetents, oh sorry, that sounded too harsh, to "increase security and reliability" and "reduce the development costs and time to market", but the most lame way to waste money is to produce language specific optimized CPUs and platforms, I don't see many Jazelle running CPU lately, do you ?
Sorry but that's just in an incoherent rant based on ignorance. There are quite a few OSes out there written in higher level languages than C and assembly that are in current use, even though most mainstream stuff is still written in C,C++ and assembly. That you don't know one (and when shown examples you always find excuse why it somehow doesn't count) is only your problem, really.
Also you are conflating commercial success with the language the OS was written in, even though those two are completely orthogonal issues. And then you use that claim that because something was a commercial failure it somehow implies that one cannot write a working OS in a high level language. Way to go, first class demagogy right there ...
Not going to waste more time here.
-
OK, it's planned for this weekend a new attempt to write a "scheduler" in assembly.
I can do it
I can do it
I can do it
Can I? :o :o :o
A simple cooperative scheduler for a 6800 only takes a dozen instructions or so. If you can't do!that then you aren't thinking clearly :)
-
Not going to waste more time here.
Agreed.
The smell of terminal cluelessness or trolling is overwhelming.
-
...
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill - dead as a door nail, before being alive, ultra-proprietary patent troll stuff.
xCORE - (almost) dead, but was living briefly and still twitching, still nobody gave a rat behind about it and then it sunk in the bucket of bad ideas, no next Atmel or STM anytime soon.
So much for the innovation, anybody with a bit of brain can imagine a CPU architecture (see OpenCores CPU section), but if it does not offer massive advantages over the existing stuff, it will be just an exercise in spending venture or EU grants money.
IMHO, the advancements in code analyzers and simulators will make the existing stuff secure enough (fast already is) without the need of introducing strange cumbersome concepts, of course if the HW guys will stop cutting corners in an attempt to squeeze the last bit of performance.
-
Not going to waste more time here.
Agreed.
The smell of terminal cluelessness or trolling is overwhelming.
I have to let you know sir, that I'm very cluefull with a terminal, so it may something else... >:D
Now, what other wonderful long dead OS was written in a long dead advanced language and what will the future bring us ?
-
C is now a major impediment to improvement just like the 80x86 ISA.
I'm not clear what you mean by that. Can you give examples?
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill is an interesting CPU architecture. The interesting thing about xCORE is the way the CPUs cooperate, rather than anything about the architecture of the CPUs.
-
xCORE - (almost) dead, but was living briefly and still twitching, still nobody gave a rat behind about it and then it sunk in the bucket of bad ideas, no next Atmel or STM anytime soon.
The xCORE dominates in some niches, like professional audio. Whether that is enough to keep the business alive long enough to broaden its appeal is the key question.
-
*Cough* Multics. *Cough*
Multics is not a good counter-example to his claim. Parts of it were written in PL/I but a large part was in assembly.
The overwhelming majority was in PL/1. From memory, two modules of any substance, the PL/1 operators and the process switch, perhaps 500 lines of code in total in what you'd call the kernel nowadays,plus a handful coding gates (just jump table entries in essence), a handful or two of short files that would have otherwise been coded as 'asm{}' had multics pl/1 had syntax for that, a handful more in BOS the system bootstrap. More was in assembler while they were bootstrapping it from nothing, but pl1_operators_.alm and the process switch where all that were left when they finished. Full disclosure, I did some systems programming on multics back in the 80s and it still holds a fond place in the panoply of operating systems as far as I'm concerned.
-
OS security is actually pretty awful. Any attempt to put a safety net under clueless programmers who drop the ball every other hour is IMHO laudable. If that turns out to be an OS written in whitespace, so be it.
-
Regarding Jazelle on Arm, has anyone ever seen it used? I'm not even sure if ARMv8 still supports it. As far as I remember it was mostly an exception mechanism that aborted into a special processor mode, from where you would run a Jit compiler to generate machine code to emulate the faulting Java byte code.
-
...
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill - dead as a door nail, before being alive, ultra-proprietary patent troll stuff.
xCORE - (almost) dead, but was living briefly and still twitching, still nobody gave a rat behind about it and then it sunk in the bucket of bad ideas, no next Atmel or STM anytime soon.
So much for the innovation, anybody with a bit of brain can imagine a CPU architecture (see OpenCores CPU section), but if it does not offer massive advantages over the existing stuff, it will be just an exercise in spending venture or EU grants money.
IMHO, the advancements in code analyzers and simulators will make the existing stuff secure enough (fast already is) without the need of introducing strange cumbersome concepts, of course if the HW guys will stop cutting corners in an attempt to squeeze the last bit of performance.
Totally agreed!
-
OS security is actually pretty awful. Any attempt to put a safety net under clueless programmers who drop the ball every other hour is IMHO laudable. If that turns out to be an OS written in whitespace, so be it.
Clueless programmers should stick to "apps", and have no need for, or use in, OS programming. Regarding the "safety nets", who checks for safety of the safety net, we definitely need a TÜV for OSes.
-
Hey look, what about writing an OS in ADA ?
In the end it was designed for this, IMNSHO is still better than Lisp, we have nice tutorials for those who want to learn:
https://learn.adacore.com/pdf_books/courses/Ada_For_The_Embedded_C_Developer.pdf (https://learn.adacore.com/pdf_books/courses/Ada_For_The_Embedded_C_Developer.pdf)
Free and OSS advanced (cross)toolchains, even a special one intended for bareboard targets (this is how you do your OS), what more to to want ? Also, you can buy professional support as well.
https://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/bareboard_topics.html
You can learn more in this short presentation video:
https://rr.noordstar.me/5818b6fa
-
C is now a major impediment to improvement just like the 80x86 ISA.
I'm not clear what you mean by that. Can you give examples?
Many other people have done that far better than I could. I liked C in the early 80s, but by the time the mid 90s had arrived it was clear that C and C++ were problems rather than answers.
I well remember the endless (over a year) debate about whether it should be possible/impossible to "cast away constness". There are good reasons for both, but they are obviously mutually incompatible.
There's the C++ FQA, of course.
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html)
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill is an interesting CPU architecture. The interesting thing about xCORE is the way the CPUs cooperate, rather than anything about the architecture of the CPUs.
A key point is multiprocessor/multiprocessing operation - but many processors have that. It is easy to make very parallel processors, but difficult to program them to make use of the parallelism.
The unique point is the tight integration of hardware capabilities with software capabilities such that together they are better than the sum.
-
OS security is actually pretty awful. Any attempt to put a safety net under clueless programmers who drop the ball every other hour is IMHO laudable. If that turns out to be an OS written in whitespace, so be it.
Clueless programmers should stick to "apps", and have no need for, or use in, OS programming. Regarding the "safety nets", who checks for safety of the safety net, we definitely need a TÜV for OSes.
As a matter of fact, TÜV does security certification to Common Criteria. But anyone can have that, if the threat model is lean enough.
Regarding Clueless programmers should stick to apps, that's just elitist crap. Rockstars are rare, supply never meets demand and if a venture relies only on them it is doomed to fail. But if your framework allows you to utilize the 'waterboys' instead of packing all the mundane tasks on your few quarterbacks, you will definitely have a competitive edge over the team of just Allstars.
-
OS security is actually pretty awful. Any attempt to put a safety net under clueless programmers who drop the ball every other hour is IMHO laudable. If that turns out to be an OS written in whitespace, so be it.
Clueless programmers should stick to "apps", and have no need for, or use in, OS programming. Regarding the "safety nets", who checks for safety of the safety net, we definitely need a TÜV for OSes.
As a matter of fact, TÜV does security certification to Common Criteria. But anyone can have that, if the threat model is lean enough.
Regarding Clueless programmers should stick to apps, that's just elitist crap. Rockstars are rare, supply never meets demand and if a venture relies only on them it is doomed to fail. But if your framework allows you to utilize the 'waterboys' instead of packing all the mundane tasks on your few quarterbacks, you will definitely have a competitive edge over the team of just Allstars.
Just so.
Plus in my experience the programmers that consider themselves "the elite" often
- don't understand as much as they think about the language. Not quite Dunning Krueger territory, but destructive enough
- concentrate on minutiae and make awful architectural decisions
-
C is now a major impediment to improvement just like the 80x86 ISA.
I'm not clear what you mean by that. Can you give examples?
Many other people have done that far better than I could. I liked C in the early 80s, but by the time the mid 90s had arrived it was clear that C and C++ were problems rather than answers.
People have loved writing "C is bad" articles" since C first appeared, but most don't really hold water.
I well remember the endless (over a year) debate about whether it should be possible/impossible to "cast away constness". There are good reasons for both, but they are obviously mutually incompatible.
Tinkering with constness is more about the use of ROM than the CPU architecture.
There's the C++ FQA, of course.
C++ doesn't count. Its so complex and quirky, it certainly does tie people's hands.
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html)
I think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill is an interesting CPU architecture. The interesting thing about xCORE is the way the CPUs cooperate, rather than anything about the architecture of the CPUs.
A key point is multiprocessor/multiprocessing operation - but many processors have that. It is easy to make very parallel processors, but difficult to program them to make use of the parallelism.
The unique point is the tight integration of hardware capabilities with software capabilities such that together they are better than the sum.
Sure, but you could do that with x86 or ARM cores. There is nothing particular about the xCORE cores that makes them special. I've encountered many people trying to tie their favourite ISA to an interesting scheme, that had almost nothing to do with the ISA.
-
I use a subset of c++ in many embedded projects. I feel the way I use it could be good within the linux kernel. Always thought there should be a "c+" specification that would be the stripped down functionality for this scenario (no stdlib, exceptions, etc).
-
I use a subset of c++ in many embedded projects. I feel the way I use it could be good within the linux kernel. Always thought there should be a "c+" specification that would be the stripped down functionality for this scenario (no stdlib, exceptions, etc).
One of the things I really missed when using C after languages like CORAL66 was the ability to bundle groups of functions into their own module. That was already becoming a common features of languages in the ALGOL sphere when C was developed. Its a pity some basic management tools like this never made their way into the C spec.
-
I use a subset of c++ in many embedded projects. I feel the way I use it could be good within the linux kernel. Always thought there should be a "c+" specification that would be the stripped down functionality for this scenario (no stdlib, exceptions, etc).
The problems arise when co-workers use a different subset, or users of your code don't understand the limitations it imposes on their code. And in C implementations that includes having the right compilation flags.
-
I use a subset of c++ in many embedded projects. I feel the way I use it could be good within the linux kernel. Always thought there should be a "c+" specification that would be the stripped down functionality for this scenario (no stdlib, exceptions, etc).
One of the things I really missed when using C after languages like CORAL66 was the ability to bundle groups of functions into their own module. That was already becoming a common features of languages in the ALGOL sphere when C was developed. Its a pity some basic management tools like this never made their way into the C spec.
I narrowly missed using CORAL66, and have long been amazed at "name collisions" in C.
-
I don't think I'm going to rush into Rust
-rwxr-xr-x 1 rstofer rstofer 8304 Apr 16 12:49 hello
-rw-r--r-- 1 rstofer rstofer 71 Apr 16 12:48 hello.c
-rwxr-xr-x 1 rstofer rstofer 3343520 Apr 16 12:47 main
-rw-r--r-- 1 rstofer rstofer 46 Apr 16 12:47 main.rs
Look at the size of the 'main' executable compared to 'hello'.
I'll concede I know absolutely nothing about Rust but I got the example here:
https://doc.rust-lang.org/book/ch01-02-hello-world.html
-
C is now a major impediment to improvement just like the 80x86 ISA.
I'm not clear what you mean by that. Can you give examples?
Many other people have done that far better than I could. I liked C in the early 80s, but by the time the mid 90s had arrived it was clear that C and C++ were problems rather than answers.
People have loved writing "C is bad" articles" since C first appeared, but most don't really hold water.
"90% of everything is crap" - but the 10% is worth understanding.
I well remember the endless (over a year) debate about whether it should be possible/impossible to "cast away constness". There are good reasons for both, but they are obviously mutually incompatible.
Tinkering with constness is more about the use of ROM than the CPU architecture.
Absolutely not. Constness is about correct operation in the presence of large programs and/or optimisation. ROMs are a side issue.
Without constness, many optimisations aren't possible because the compiler cannot determine the absence of aliasing. Even then, having the wrong compilation flags introduces all sorts of intermittent bugs.
With constness, how can a debugger operate?
There's the C++ FQA, of course.
C++ doesn't count. Its so complex and quirky, it certainly does tie people's hands.
No argument there. If C++ is is the answer, you asked the wrong question.
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html)
I think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!
Until very recently, C didn't even have a memory model. How successful its current memory model will be remains to be seen. It is a very difficult area; even Java had to modify the memory model in the light of experience.
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill is an interesting CPU architecture. The interesting thing about xCORE is the way the CPUs cooperate, rather than anything about the architecture of the CPUs.
A key point is multiprocessor/multiprocessing operation - but many processors have that. It is easy to make very parallel processors, but difficult to program them to make use of the parallelism.
The unique point is the tight integration of hardware capabilities with software capabilities such that together they are better than the sum.
Sure, but you could do that with x86 or ARM cores. There is nothing particular about the xCORE cores that makes them special. I've encountered many people trying to tie their favourite ISA to an interesting scheme, that had almost nothing to do with the ISA.
Correct. There was even an XMOS processor that included an ARM core!
Nonetheless, the combination of i/o ports, comms fabric, multiprocessor cores, language and IDE tools is unparalleled (ho ho ho). It is the unified vision plus implementation of the vision that is unique.
I also hope it is not the last word - we need as much help as we can get with highly parallel systems. There are encouraging signs: other modern languages are incorporating some of the CSP and xC concepts more or less directly. Such languages are learning from the past, not being constrained by it.
-
I don't think I'm going to rush into Rust
Wise decision; neither am I!
-rwxr-xr-x 1 rstofer rstofer 8304 Apr 16 12:49 hello
-rw-r--r-- 1 rstofer rstofer 71 Apr 16 12:48 hello.c
-rwxr-xr-x 1 rstofer rstofer 3343520 Apr 16 12:47 main
-rw-r--r-- 1 rstofer rstofer 46 Apr 16 12:47 main.rs
Look at the size of the 'main' executable compared to 'hello'.
I'll concede I know absolutely nothing about Rust but I got the example here:
https://doc.rust-lang.org/book/ch01-02-hello-world.html
But microbenchmarks - which might be invalidated tomorrow - are not a good basis for avoiding any language.
-
I don't think I'm going to rush into Rust
Wise decision; neither am I!
-rwxr-xr-x 1 rstofer rstofer 8304 Apr 16 12:49 hello
-rw-r--r-- 1 rstofer rstofer 71 Apr 16 12:48 hello.c
-rwxr-xr-x 1 rstofer rstofer 3343520 Apr 16 12:47 main
-rw-r--r-- 1 rstofer rstofer 46 Apr 16 12:47 main.rs
Look at the size of the 'main' executable compared to 'hello'.
I'll concede I know absolutely nothing about Rust but I got the example here:
https://doc.rust-lang.org/book/ch01-02-hello-world.html
But microbenchmarks - which might be invalidated tomorrow - are not a good basis for avoiding any language.
But even this simple test can serve to dissuade a programmer from trying a language that, at best, is a poor substitute for C. C has been around a while, I expect it to join Fortran and COBOL as one of the long lasting languages.
I know, everybody is laughing at the geezer geek! Well, there is an nvfortran compiler for NVIDIA GPU programming. I don't see that it works on the Jetson Nano platform but it certainly works on the graphic board GPUs.
And banking still relies on COBOL. If you get cash from an ATM, chances are the banking end of the code was written in COBOL.
Fortran introduced in 1957 (created in 1954)
COBOL introduced in 1959
C introduced in 1972
C++ introduced in 1985
Rust introduced in 2013 - 56 years after Fortran and 41 years after C
-
One of my favorites is the Lilith workstation by Niklaus Wirth on which everything was coded in Modula-2 including the OS. See https://en.wikipedia.org/wiki/Lilith_%28computer%29
Ben
-
I don't think I'm going to rush into Rust
Wise decision; neither am I!
-rwxr-xr-x 1 rstofer rstofer 8304 Apr 16 12:49 hello
-rw-r--r-- 1 rstofer rstofer 71 Apr 16 12:48 hello.c
-rwxr-xr-x 1 rstofer rstofer 3343520 Apr 16 12:47 main
-rw-r--r-- 1 rstofer rstofer 46 Apr 16 12:47 main.rs
Look at the size of the 'main' executable compared to 'hello'.
I'll concede I know absolutely nothing about Rust but I got the example here:
https://doc.rust-lang.org/book/ch01-02-hello-world.html
But microbenchmarks - which might be invalidated tomorrow - are not a good basis for avoiding any language.
But even this simple test can serve to dissuade a programmer from trying a language that, at best, is a poor substitute for C. C has been around a while, I expect it to join Fortran and COBOL as one of the long lasting languages.
You are aware, I presume, that there are serious moves to enable Rust in the Linux kernel.
As I see it, one of the less tractable problems is that it relies on the LLVM compiler, not gcc.
-
I just followed the directions using Ubuntu under Win 10. I did no other research.
-
I just followed the directions using Ubuntu under Win 10. I did no other research.
I guess you are referring to my post noting the moves to have Rust in the Linux kernel.
It sounds like your negative opinion is based on inexperience with using the tool.
My inexperience leads me to sit on the fence, on the basis that there are significant potential benefits, but they haven't been demonstrated to my limited knowledge.
You may care to read:
https://www.phoronix.com/scan.php?page=news_item&px=Torvalds-Rust-Kernel-K-Build (https://www.phoronix.com/scan.php?page=news_item&px=Torvalds-Rust-Kernel-K-Build)
https://www.phoronix.com/scan.php?page=news_item&px=Rust-Hits-Linux-Next (https://www.phoronix.com/scan.php?page=news_item&px=Rust-Hits-Linux-Next)
https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-April-2021-RFC (https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-April-2021-RFC)
-
I don't think I'm going to rush into Rust
-rwxr-xr-x 1 rstofer rstofer 8304 Apr 16 12:49 hello
-rw-r--r-- 1 rstofer rstofer 71 Apr 16 12:48 hello.c
-rwxr-xr-x 1 rstofer rstofer 3343520 Apr 16 12:47 main
-rw-r--r-- 1 rstofer rstofer 46 Apr 16 12:47 main.rs
Look at the size of the 'main' executable compared to 'hello'.
I'll concede I know absolutely nothing about Rust but I got the example here:
https://doc.rust-lang.org/book/ch01-02-hello-world.html
The standard library is linked statically by default, though your binary is still an order of magnitude larger than mine for some reason. If you do dynamic linking, comparable to the default with C, it's down to 20KB on my system which is barely larger than what gcc emits. The statically linked C binary is actually larger than Rust's.
Not that this is really a great reason to choose a language. These days the size of the binary on disk is more or less irrelevant for almost all code.
$ rustc main.rs
$ du -h main
336K main
$ rustc -C prefer-dynamic main.rs
$ du -h main
20K main
$ gcc -o main main.c
$ du -h main
16K main
$ gcc -static -o main main.c
$ du -h main
952K main
-
I used these instructions for installation (Section 1.1)
https://doc.rust-lang.org/book/ch01-01-installation.html
and this HelloWorld example (Section 1.2)
https://doc.rust-lang.org/book/ch01-02-hello-world.html
I didn't pursue the topic beyond looking at the size of the executable.
And what's with the 'macro' notation with the ! symbol?
println!("Hello World");
Seriously?
-
I used these instructions for installation (Section 1.1)
https://doc.rust-lang.org/book/ch01-01-installation.html
and this HelloWorld example (Section 1.2)
https://doc.rust-lang.org/book/ch01-02-hello-world.html
I didn't pursue the topic beyond looking at the size of the executable.
It appears that your principal objective was to find an excuse to dismiss the language.
-
The standard library is linked statically by default, though your binary is still an order of magnitude larger than mine for some reason. If you do dynamic linking, comparable to the default with C
Just to be clear, by 'static' linking you mean shoving library code in the executable, and by 'dynamic' you mean having the library code loaded at run-time? If so, that's a bit disingenuous since the executing application still needs the same linked-in code, just that with dynamic linking you don't count it. Put all the necessary stuff in one place and see what the size is - that's what it takes to run it.
And, in fact, all other things being equal, running a single executable with dynamic linking leads to more bloat since every library function will be required regardless as to whether it's used or not. With static linking only the bits actually used get linked in (or should be).
-
Why is everybody ignoring and not mentioning ADA, the best way that is not C/C++ to write an operating system ?
"The Army Secure Operating System (ASOS) was written almost entirely in Ada. It was designed to meet Orange Book A1 protection requirements, support Ada applications more directly, and run on a commodity Sun3. The total software was 55,000 lines of code. It even had checkpointing/restore and later a secure RDBMS."
Here, freshly declassified:
https://apps.dtic.mil/dtic/tr/fulltext/u2/a340370.pdf
https://moscow.sci-hub.se/1864/6e4bd79db1e4753ea76c251441a45133/waldhart1990.pdf
This was what real programmers were doing before CoC and other hipster shite.
-
The standard library is linked statically by default, though your binary is still an order of magnitude larger than mine for some reason. If you do dynamic linking, comparable to the default with C
Just to be clear, by 'static' linking you mean shoving library code in the executable, and by 'dynamic' you mean having the library code loaded at run-time? If so, that's a bit disingenuous since the executing application still needs the same linked-in code, just that with dynamic linking you don't count it. Put all the necessary stuff in one place and see what the size is - that's what it takes to run it.
Fair enough. If you want to do that then you need to compile the C code with -static as well.
On my x86_64 Linux compiling helloWorld I get:
dynamic: 1508 bytes program code, 600 bytes data, 8 bytes bss
static: 743321 bytes program code, 20876 bytes data, 5984 bytes bss
And, in fact, all other things being equal, running a single executable with dynamic linking leads to more bloat since every library function will be required regardless as to whether it's used or not. With static linking only the bits actually used get linked in (or should be).
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
-
If I remember well, Motorola VersaDOS was written entirely in 68k assembler. A byte-coded Pascal interpreter, painfully slow, was available from the original installation disks.
-
This morning I wrote an "interactive mean function" to fix a couple of problems I had on two sensors. Both the ultrasonic and IR reflective sensors are noisy and their means tend to overflow.
In the past I embedded a smart mean function within each "sensor driver", it worked, it was guaranteed to not overflow, but it wasted precious code space.
The ADC used for the reflective sensor was 8bit now it's 12 bit, the free running timer used for the ultrasonic sensor is 16bit, what I wrote this morning is one the mean-function that does the job nicely for both of them.
It was funny to do, not exactly easy but funny, but also doing it in assembly also allowed me to make the function able to invoke several methods by just having its base_address in a "index" register passed as argument.
value0 = mean_get(get_addr(sensor0) /* callback */ );
value1 = mean_get(get_addr(sensor1) /* callback */ );
output: reg D is the function returned value
input: reg X is the callback to the sensor, method requires index+service
used services: get_data, get_window_size
wasted registers: D,X
The mean function can invoke "sensor.data_get" and "sensor.get_window_size" methods from both the sensors by just having the base address passed by a register like if it was a callback in C.
The MPU is able to perform jsr X, and X is calculated as sensor_base + method, I exploited a trick offered by the linker script to have the method addresses expressed as relative to the base_address.
The strange but funny thing is that doing it in assembly + linker script was much simpler and less byte consuming than writing it in C :o :o :o
Next step, rewriting them as "task" for the scheduler with an additional "sensor fusion" task.
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
-
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html)
I think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!
Try reading what I wrote again without the bad attitude. Hans Boehm is an important figure who pointed out a lot of sloppy thinking related to how poorly understood hardware memory models interact with threading and multi-CPU environments. I don't see how this makes running C code an impediment to progress. Single threaded C code has no real issues. Mullti-threaded C code certainly inhibits change, but so does every other kind of multi-threaded code. They are ALL incompatible with change.
-
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html)
I think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!
Try reading what I wrote again without the bad attitude. Hans Boehm is an important figure who pointed out a lot of sloppy thinking related to how poorly understood hardware memory models interact with threading and multi-CPU environments. I don't see how this makes running C code an impediment to progress. Single threaded C code has no real issues. Mullti-threaded C code certainly inhibits change, but so does every other kind of multi-threaded code. They are ALL incompatible with change.
I have never claimed anything similar to "makes running C code an impediment to progress".
C code including single-threaded code - as found in the wild - does have many issues.
I have no idea what you mean by "Mullti-threaded C code certainly inhibits change, but so does every other kind of multi-threaded code. They are ALL incompatible with change."
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
If you want something different, try the Hindley–Milner type system languages -- and even most of those are not *so* different, except Haskell.
-
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
-
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
Right. Most big things are big because of the working data, not the code. I have libraries of a couple of hundred k, that take up gigabytes on running systems, because so many instances are used, and each instance has a lot of working data.
I'm not sure the original intent of dynamic link libraries was mostly about memory saving. The ability to swap out one bug fixed library, and fix every app using it, was an important driving force. That's more an area where the hype didn't work out well, as we fell into a DLL hell that the industry has taken a long time to cilmb out of.
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
-
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
Right. Most big things are big because of the working data, not the code. I have libraries of a couple of hundred k, that take up gigabytes on running systems, because so many instances are used, and each instance has a lot of working data.
I'm not sure the original intent of dynamic link libraries was mostly about memory saving. The ability to swap out one bug fixed library, and fix every app using it, was an important driving force. That's more an area where the hype didn't work out well, as we fell into a DLL hell that the industry has taken a long time to cilmb out of.
There are people out there that have the opinion that static linking is bad practice but they don't have problems with flatpak or snap...
-
According to https://www.merriam-webster.com (https://www.merriam-webster.com) an operating system is "software that controls the operation of a computer and directs the processing of programs (as by assigning storage space in memory and controlling input and output functions)"
So Forth is a good example of a OS not generally written in C/C++ but it could be.
I have Forths written in just about everything including Scheme, Bash, Perl and many others, but the one I use everyday is written in ARM Thumb1 assembly language.
-
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
I'm really not sure what your point is here.
We're talking about code size.
Initialized data from a dynamic library is shared, until a program writes to it, at which time it gets its own writable copy of that memory page. Constant data remains always shared -- at least as long as it is not intermingled on the same memory page with data that is modified. Since data the compiler knows to be constant is put in a different section to initialised data that the compiler expects to be modified, each type is gathered together and there should be at most one memory page (but quite likely zero) per library with a mix of constant and modifiable initialized data.
RSS data is not shared, but then it is not present in the program or library files at all.
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code. What problems there are are generally caused by using poorly designed libraries (including the convenient but dangerous standard library).
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman
What problems there are are generally caused by using poorly designed libraries (including the convenient but dangerous standard library).
Q.E.D. :)
-
Why is everybody ignoring and not mentioning ADA, the best way that is not C/C++ to write an operating system ?
"The Army Secure Operating System (ASOS) was written almost entirely in Ada. It was designed to meet Orange Book A1 protection requirements, support Ada applications more directly, and run on a commodity Sun3. The total software was 55,000 lines of code. It even had checkpointing/restore and later a secure RDBMS."
Here, freshly declassified:
https://apps.dtic.mil/dtic/tr/fulltext/u2/a340370.pdf
https://moscow.sci-hub.se/1864/6e4bd79db1e4753ea76c251441a45133/waldhart1990.pdf
There is more recent stuff:
https://marte.unican.es/
https://m2os.unican.es/
-
Linus Torvalds Says Rust Closer for Linux Kernel Development, Calls C++ 'A Crap Language': https://developers.slashdot.org/story/21/04/17/009241/linus-torvalds-says-rust-closer-for-linux-kernel-development-calls-c-a-crap-language
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman
That is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman
That is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
So you think it is ana acceptable argument to exclude "half" of C uses and concentrate on the less inconvenient other half?
More interestingly, you highlight a problem that C and C++ made for themselves in the early/mid 90s....
There was two directions in which C could go: be a general purpose high level applications language, or be a low level systems programming language. Either would have been a good choice with a good result, but the standards committees couldn't decide and fudged the issue. The result is that they are less good for either.
One example of the dichotomy was the endless arguments over whether is must be possible/impossible to "cast away fondness". High level applications require it to be impossible, since constness guarantees enable large scale performance optimisations. Low level systems require it in,, for example, debuggers.
The deficiencies were most noticeable in the applications domain, so now Java, Python and possibly Rust are dominant.
Personally I'd have preferred it if C had remained optimise for systems programming, since there were already better languages available, and C++ was clearly the wrong answer to any useful question.
-
..., so now Java, Python and possibly Rust are dominant.
(https://www.eevblog.com/forum/programming/any-examples-of-os-not-written-in-cc/?action=dlattach;attach=1212107)
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
-
..., so now Java, Python and possibly Rust are dominant.
(https://www.eevblog.com/forum/programming/any-examples-of-os-not-written-in-cc/?action=dlattach;attach=1212107)
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
Tiobe doesn't measure anything useful, let alone something related to the part of the sentence you omitted.
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman
That is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
So you think it is an acceptable argument to exclude "half" of C uses and concentrate on the less inconvenient other half?
No, I think it is an error to consider hosted C environment the only valid C, and call relying on freestanding C 'excluding "half" of C', when the main problems are all in the hosted C environment only.
The above linked argument is not a case of No True Scotsman, exactly because of the dual nature of the C standard, and the problems being avoidable by using freestanding C. It is a valid argument, because many C developers are not aware of the differences between the hosted environment and the freestanding environment, and conflate the two.
(Technically, one does not even need to write freestanding C, just avoid using most of the standard C library API; and use other APIs, like say Boehm GC for memory allocation, and mutable data buffers with explicit bounds instead of standard C strings, to basically completely avoid both buffer overruns and dynamic memory management problems.)
I fully agree that the C standard committee has dropped the ball over two decades ago, mainly due to increased vendor pressure and complete rejection of the POSIX standard, and instead veering into C++ and vendor-specific optional interfaces (like the so-called "safe I/O functions", which are nothing of the sort).
Put another way, buffer overruns and dynamic memory management issues are not an inherent part of C; only an inherent part of the library that forms the core of the hosted C environment: the standard C library. It is quite possible, and indeed very feasible, to either replace, or just augment the standard C library with something completely different that 1) does not suffer from buffer overruns because array boundaries are part of the data structures used by the replacement library interfaces, and 2) has an efficient automatic garbage collection; and the code will still be C that a typical C developer will be able to read and maintain. To develop such code, a typical C developer will have to learn those new interfaces, but that's it.
Having experimented and delved into this, it amazes me that no real work has been published on this front, because I'm basically drowning in possibilities and having to write a lot of test code just to see which options I prefer right now, for code running under the Linux kernel on typical ARM and Intel hardware.
To me, it feels like computer scientists are arguing amongst themselves how many sides should a polygonal wheel have, completely ignoring round, circular wheels... We really have not made much real progress in software engineering (and I'm suspecting in computer science too) in the last two or three decades. Small optimizations only.
Things like the Arduino library (which replaces the standard C library for Arduino development; and although the code is compiled using a C++ compiler, it relies on the GNU C++ compiler providing a freestanding C++ environment based on the C freestanding environment) are honestly quite horrible, possibly even worse than the standard C library. I shan't talk much about the various vendor-provided Hardware Abstraction Libraries, just that every single one I've seen has been a disappointment (in the software engineering sense – compare to a contractor seeing a house built with timber but using twine instead of nails or screws (or even pegs) to hold things together).
The dual nature is important to realize, because the non-library part of C is so simple yet powerful. It could be much better (code-level concurrency, barriers, memory semantics/coherency etc.), but that sort of stuff is better explored with other languages. However, the C library part, which is not a compulsory/required part of C, only an optional part, is the biggest problem with C, and is easily replaced with something else. (That is, all C compilers I have used, provide compile time flags and options that allow trivially replacing/omitting the standard C library with something else.)
-
I'd like to play with a simple OS not written in C/C++.
How much do you consider "a simple OS"?
I mean, it's pretty trivial (and frequently necessary) to write task switching in assembly language, and not much more effort to add a simple scheduler. That might be all you need to count as an OS in embedded spaces; just figure out how you're going to interface it to application code that is perhaps written in a different language...
But that's very much less than what would be considered a "small OS" for a slightly bigger computer - you'd have to at least add a file-system and a network stack, a windowing system, and probably a whole suite of core user-level applications - when one talks about linux or Windows as being an OS it's not done till it includes at least one web browser, a fancy file manager, and a game...
-
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome :D
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman (https://en.m.wikipedia.org/wiki/No_true_Scotsman)
That is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
So you think it is an acceptable argument to exclude "half" of C uses and concentrate on the less inconvenient other half?
No, I think it is an error to consider hosted C environment the only valid C, and call relying on freestanding C 'excluding "half" of C', when the main problems are all in the hosted C environment only.
The above linked argument is not a case of No True Scotsman, exactly because of the dual nature of the C standard, and the problems being avoidable by using freestanding C. It is a valid argument, because many C developers are not aware of the differences between the hosted environment and the freestanding environment, and conflate the two.
(Technically, one does not even need to write freestanding C, just avoid using most of the standard C library API; and use other APIs, like say Boehm GC for memory allocation, and mutable data buffers with explicit bounds instead of standard C strings, to basically completely avoid both buffer overruns and dynamic memory management problems.)
I fully agree that the C standard committee has dropped the ball over two decades ago, mainly due to increased vendor pressure and complete rejection of the POSIX standard, and instead veering into C++ and vendor-specific optional interfaces (like the so-called "safe I/O functions", which are nothing of the sort).
Put another way, buffer overruns and dynamic memory management issues are not an inherent part of C; only an inherent part of the library that forms the core of the hosted C environment: the standard C library. It is quite possible, and indeed very feasible, to either replace, or just augment the standard C library with something completely different that 1) does not suffer from buffer overruns because array boundaries are part of the data structures used by the replacement library interfaces, and 2) has an efficient automatic garbage collection; and the code will still be C that a typical C developer will be able to read and maintain. To develop such code, a typical C developer will have to learn those new interfaces, but that's it.
Having experimented and delved into this, it amazes me that no real work has been published on this front, because I'm basically drowning in possibilities and having to write a lot of test code just to see which options I prefer right now, for code running under the Linux kernel on typical ARM and Intel hardware.
To me, it feels like computer scientists are arguing amongst themselves how many sides should a polygonal wheel have, completely ignoring round, circular wheels... We really have not made much real progress in software engineering (and I'm suspecting in computer science too) in the last two or three decades. Small optimizations only.
Things like the Arduino library (which replaces the standard C library for Arduino development; and although the code is compiled using a C++ compiler, it relies on the GNU C++ compiler providing a freestanding C++ environment based on the C freestanding environment) are honestly quite horrible, possibly even worse than the standard C library. I shan't talk much about the various vendor-provided Hardware Abstraction Libraries, just that every single one I've seen has been a disappointment (in the software engineering sense – compare to a contractor seeing a house built with timber but using twine instead of nails or screws (or even pegs) to hold things together).
The dual nature is important to realize, because the non-library part of C is so simple yet powerful. It could be much better (code-level concurrency, barriers, memory semantics/coherency etc.), but that sort of stuff is better explored with other languages. However, the C library part, which is not a compulsory/required part of C, only an optional part, is the biggest problem with C, and is easily replaced with something else. (That is, all C compilers I have used, provide compile time flags and options that allow trivially replacing/omitting the standard C library with something else.)
Thanks for a thoughtful and nuanced post. I stand by my original points.
I thank you for providing even more points indicating why C/C++ has become part of the problem rather than a solution. :)
I'll highlight and comment on a few of your points below...
many C developers are not aware of the differences between the hosted environment and the freestanding environment, and conflate the two.
Which is unsurprising, since the committee and language conflate the two - to the detriment of both.
I fully agree that the C standard committee has dropped the ball over two decades ago, mainly due to increased vendor pressure
I'm unconvinced vendor pressure was the main reason for problems. As one example, the "cast away constness" dilemma is a fundamental consequence of the application domains and fundamental properties of the language.
Put another way, buffer overruns and dynamic memory management issues are not an inherent part of C;
Not true, since pointers can point to anything including memory outside buffers - and neither the language nor runtime can detect it. There are common workarounds/clichés, but they rely on programmers religiously understanding and following the workarounds/clichés - and in many environments there are incentives working against that. In an ideal world that wouldn't be the case, but here on planet earth... :(
To me, it feels like computer scientists are arguing amongst themselves how many sides should a polygonal wheel have, completely ignoring round, circular wheels... We really have not made much real progress in software engineering (and I'm suspecting in computer science too) in the last two or three decades. Small optimizations only.
I tend to agree, unfortunately. When returning to embedded programming recently, I was horrified at how little had changed since the early 80s.
However, there have been some advances since then, notably decent OOP, and the recognition that single-threaded code is no longer a good starting point and must be a designed pre-requisite in the future. The latter is currently far from perfect, and I hope more advances will be made - but there are promising signs.
Things like the Arduino library ... are honestly quite horrible, possibly even worse than the standard C library. I shan't talk much about the various vendor-provided Hardware Abstraction Libraries
Agreed, but I don't think the language can be blamed for those! It is, however, a shame that it didn't encourage better.
McCormicks well known Ada vs C model railroad experiments threw up some surprising insights http://archive.adaic.com/projects/atwork/trains.html (http://archive.adaic.com/projects/atwork/trains.html)
The dual nature is important to realize, because the non-library part of C is so simple yet powerful.
Powerful, but not simple. And the dual nature means it is an unsatisfactory fudge for both.
It could be much better (code-level concurrency, barriers, memory semantics/coherency etc.), but that sort of stuff is better explored with other languages.
Those are fundamental and it is finally being recognised that they are critical in multiprocessor systems. And even cheap embedded systems are multicore nowadays.
However, the C library part, which is not a compulsory/required part of C, only an optional part, is the biggest problem with C, and is easily replaced with something else.
Technically perhaps, but practically and commercially not!
-
Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.
To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.
-
Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.
To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.
The original standard C library is certainly a problem. Its full of functions with no internal size checks. A good library isn't a magic cure for problems, but the original standard C library is like a banana skin.
-
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
If you believe that, how do you explain the regular exploits like:
100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
Gabe Goldberg <gabe@gabegold.com>
Wed, 14 Apr 2021 19:41:06 -0400
The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/ (https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/)
or
A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
Amos Shapir <amos083@gmail.com>
Fri, 16 Apr 2021 17:49:35 +0300
Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
https://www.entrepreneur.com/article/368943 (https://www.entrepreneur.com/article/368943)
Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/ (https://catless.ncl.ac.uk/Risks/)
-
Can't believe I missed this thread. Right up my street.
100% agree with you. There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible. The problem is the compiler's fundamental model is memory regardless of what suit you dress your code in, whichever macros or libraries you use, whether or not Coverity have buggered you for cash or not and whether or not you have used clever compiler features to trip up people attacking your code.
99% of programs written though, why the hell would you give the average "engineer" (in quotes intentionally) two loaded shot guns, a backpack full of knives. All they're going to do is spread their own form of electric ebola...
These days if we need suitable guard rails, we look towards fully managed runtimes (think Java, .Net, Python) and better abstracted memory-safe languages (Go) even at system level. That covers that crapfest nicely, leaving the entire class of application domain bugs open instead which is more than enough of a problem on its own without having to worry about driving up the pavement into a lamp post.
I don't really give a fuck about the OS quite frankly though. The key thing is it's as small as possible and lets me run my programs without getting in the way of them. Amazon will rent you a nice mainframe that hides that from you.
Edit: I didn't even mention rust. Discounted due to certain people marketing it as Jesus' sandals. Been around long enough to know what's going to stick and what isn't.
-
Can't believe I missed this thread. Right up my street.
100% agree with you. There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible. The problem is the compiler's fundamental model is memory regardless of what suit you dress your code in, whichever macros or libraries you use, whether or not Coverity have buggered you for cash or not and whether or not you have used clever compiler features to trip up people attacking your code.
Precisely.C/C++ memory is untyped, even if the variables are strongly typed. Fashionable modern languages tend to have strongly typed memory and untyped variables. Personally I like strongly typed memory and typed variables.
-
Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.
To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.
The original standard C library is certainly a problem. Its full of functions with no internal size checks. A good library isn't a magic cure for problems, but the original standard C library is like a banana skin.
Yes, of course strcpy() and the like are obviously problematic, but there are countless patterns of unsecure code aside from that. The concept of pointer arithmetics or integer indices to access arbitrary memory locations, while mightily convenient for low-level hardware hacking, is inherently unsafe. Not to mention the plethora of cases where behavior is simply "undefined" in C.
-
Yep. There's even a competition to see what you can get away with :-DD
http://www.underhanded-c.org/ (http://www.underhanded-c.org/)
This is a fun one from it:
typedef double float_t;
-
I stand by my original points.
I really only object to the No True Scotsman fallacy claim.
I'll highlight and comment on a few of your points below...
I understand your points, and fully acknowledge their basis in facts; I only disagree on some of your conclusions.
As an example, consider PHP, a widely used but usually pretty horrible code. Especially its earlier versions were basically a security hole waiting to happen (magic quotes stuff in particular). Yet, one could write quite secure web service code with it, if one paid sufficient attention, and avoided using the features that usually lead to security problems. I know, because I have.
However, many of those security holes have been plugged (like magic quotes no longer supported, database interfaces switching from building query strings to using variable references so quoting is not even an issue, and so on). The most problematic design principle currently is that most PHP services are designed to be able to upgrade themselves, which necessarily means the installation is vulnerable to script drops/bombs et cetera. We could avoid that, and even things like password leaks, if we leveraged the POSIX/Unix user and group hierarchies, with server interpreters refusing to execute code owned by the user that can upload content to the server; and login/logout/account management facilities restricted to a few specific pages with all others not even having access to the sensitive fields of the user database...
We could do better with Python, but unfortunately Python insists on its "own" WSGI interfaces (as opposed to say FastCGI). (In particular, a page engine can be written as a FastCGI script, with each request (connection) served by a forked child. The engine can preload each instance by the main data structures, like navigation and file types supported, deduplicating most of the work done by most page loads.) As a result, typical widely used Python-based web services are vulnerable to similar bugs as PHP ones, on top of its own WSGI ones! No true forward development, just.. steps in odd directions, in my opinion.
This "proves" to me that the current software bugs and insecurity is really not a feature of the respective programming languages, but a consequence of us human developers accepting a software "engineering" culture that has discarded almost all good engineering principles, and is just sticking stuff together with spit and bubblegum, banking on the product working just long enough that they won't be held responsible for the crappiness. And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.
(I am not sure whether I can even honestly call *current* PHP versions an insecure programming language, anymore. I have in the past, especially due to features like magic quotes that attempts to hand-hold bad developers; but the removal of such has removed my reasons. Granted, I haven't written security-sensitive PHP in almost a decade now, so I am out of touch.)
There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible.
I agree; but I also think it is not necessary for a systems programming language to be "safe".
That is, one of the reasons I think C is powerful, is exactly because it does not try to stop developers from shooting themselves in the face with pointers et cetera.
Anyway, it is technically possible to write secure, robust C code. It is just much easier to write horribly buggy and insecure C code. At the core is (at least my observation that) making the language "safe" seems to also make it less powerful, harder to interface to, and/or slower: not exactly acceptable tradeoffs for the kind of situations C is used for.
Can we do better? Absolutely we can! But personally, I'm checking out the cost/benefit ratio of reaching for the low-hanging fruit first, by replacing the standard C library with something better suited for systems programming, to see how much better it would be. Perfect is the enemy of good.
-
Can low level programming be made totally "safe" just from features of the language itself?
Rust if often considered for replacing C in that area lately. But I've also read a couple papers that tend to show any serious low-level programming in Rust would require the use of "unsafe" sections of code, and that "unsafe" Rust is NOT provably any better than C. Of course you can restrict the use of unsafe sections to the strict minimum needed, whereas in C, any portion of code could be seen as unsafe - as per the Rust definition. So while it is natural to assume that it would drastically lower the probability of bugs and exploits, it remains to be proven in practice, at the level of a full OS for instance.
I agree with Nominal Animal about good engineering practice being largely replaced with silver bullets and tools.
Now C (and C++) certainly allows developers to do particularly nasty things with memory. Yes it's spectacularly easy to do so.
Various security reports I have read don't show C as the language with the most security exploits though in practice. I would have to dig a little now to provide links, but AFAIR, PHP, Javascript and even Java came largely sad winners here. It doesn't necessarily show anything related to the languages themselves though, but rather *how* (and probably by whom) they are typically used.
-
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
If you believe that, how do you explain the regular exploits like:
100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
Gabe Goldberg <gabe@gabegold.com>
Wed, 14 Apr 2021 19:41:06 -0400
The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/ (https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/)
or
A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
Amos Shapir <amos083@gmail.com>
Fri, 16 Apr 2021 17:49:35 +0300
Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
https://www.entrepreneur.com/article/368943 (https://www.entrepreneur.com/article/368943)
Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/ (https://catless.ncl.ac.uk/Risks/)
I explain those by pointing out that possible ≠ easy.
It is much, much easier to write buggy C than it is to write robust, secure C code. C is a dangerous tool, but so powerful and useful that many choose to use it nevertheless.
Nothing is perfect, so where do you draw the line for "safe"? Even if the code is guaranteed to work perfectly for all possible inputs on standard hardware, there are glitches. Most current AMD64 architecture laptop and desktop machines do not support ECC memory, so single-bit errors can occur because of an odd cosmic ray, or for a number of other reasons.
I don't think it is a No True Scotsman argument to say something like "a properly trained person will never point a firearm at anything or anyone, even when the safety is on, unless they are ready to kill them". This is a simple rule known for as long as firearms have existed; but the firearm itself does not enforce the rule. A lot of people (including soldiers) do not know or neglect to follow that rule, so accidents happen, and people get killed. With C, bugs and security failures occur often because the developers do not care (about making the code secure against unexpected inputs); I've heard countless times that "we don't have the time for that right now; we'll add those in later".
-
I stand by my original points.
I really only object to the No True Scotsman fallacy claim.
I'll highlight and comment on a few of your points below...
I understand your points, and fully acknowledge their basis in facts; I only disagree on some of your conclusions.
As an example, consider PHP, a widely used but usually pretty horrible code. Especially its earlier versions were basically a security hole waiting to happen (magic quotes stuff in particular). Yet, one could write quite secure web service code with it, if one paid sufficient attention, and avoided using the features that usually lead to security problems. I know, because I have.
However, many of those security holes have been plugged (like magic quotes no longer supported, database interfaces switching from building query strings to using variable references so quoting is not even an issue, and so on). The most problematic design principle currently is that most PHP services are designed to be able to upgrade themselves, which necessarily means the installation is vulnerable to script drops/bombs et cetera. We could avoid that, and even things like password leaks, if we leveraged the POSIX/Unix user and group hierarchies, with server interpreters refusing to execute code owned by the user that can upload content to the server; and login/logout/account management facilities restricted to a few specific pages with all others not even having access to the sensitive fields of the user database...
We could do better with Python, but unfortunately Python insists on its "own" WSGI interfaces (as opposed to say FastCGI). (In particular, a page engine can be written as a FastCGI script, with each request (connection) served by a forked child. The engine can preload each instance by the main data structures, like navigation and file types supported, deduplicating most of the work done by most page loads.) As a result, typical widely used Python-based web services are vulnerable to similar bugs as PHP ones, on top of its own WSGI ones! No true forward development, just.. steps in odd directions, in my opinion.
Not knowing PHP (because web servers bore me almost as much as databases), I presume your comments are correct. However PHP's awfulness doesn't make C any better.
As for Python, it seems reasonable enough except for
- repeating (in spades!)the makefile mistake where whitespace is semantically important
- the global interpreter lock, which avoid all sorts of problems at the expense of removing many interesting and useful performance properties
This "proves" to me that the current software bugs and insecurity is really not a feature of the respective programming languages, but a consequence of us human developers accepting a software "engineering" culture that has discarded almost all good engineering principles, and is just sticking stuff together with spit and bubblegum, banking on the product working just long enough that they won't be held responsible for the crappiness.
I completely agree, unfortunately.
And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.
Again, agreed.
But when the fundamental properties of a language mean that large applications are "castles built on sand", we shouldn't shy away from recognising that choosing a different language ought to mean the "castle is built on rock". It is, of course, possible to choose a different language so that the "castle is built on a swamp".
We should distinguish swamps and sand from rock, and choose rock whereever possible.
-
Can low level programming be made totally "safe" just from features of the language itself?
I doubt it. Halting problem and all that.
But that isn't a reason for choosing a language that avoids common problems.
I agree with Nominal Animal about good engineering practice being largely replaced with silver bullets and tools.
Good engineering practice requires avoiding use of inappropriate tools. There are no silver bullets, but some tools will allow a bigger job to be finished faster and better - by letting you concentrate on the application's problem rather than the tools' problems.
Various security reports I have read don't show C as the language with the most security exploits though in practice. I would have to dig a little now to provide links, but AFAIR, PHP, Javascript and even Java came largely sad winners here. It doesn't necessarily show anything related to the languages themselves though, but rather *how* (and probably by whom) they are typically used.
Naively counting such things rarely leads to enlightenment!
-
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
If you believe that, how do you explain the regular exploits like:
100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
Gabe Goldberg <gabe@gabegold.com>
Wed, 14 Apr 2021 19:41:06 -0400
The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/ (https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/)
or
A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
Amos Shapir <amos083@gmail.com>
Fri, 16 Apr 2021 17:49:35 +0300
Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
https://www.entrepreneur.com/article/368943 (https://www.entrepreneur.com/article/368943)
Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/ (https://catless.ncl.ac.uk/Risks/)
I explain those by pointing out that possible ≠ easy.
It is much, much easier to write buggy C than it is to write robust, secure C code. C is a dangerous tool, but so powerful and useful that many choose to use it nevertheless.
And so the obvious conclusions are that in most cases C isn't the most appropriate tool, and that we should continue to search for better replacements.
Nothing is perfect, so where do you draw the line for "safe"? Even if the code is guaranteed to work perfectly for all possible inputs on standard hardware, there are glitches. Most current AMD64 architecture laptop and desktop machines do not support ECC memory, so single-bit errors can occur because of an odd cosmic ray, or for a number of other reasons.
From yesterday's comp.risks, again
Cosmic rays causing 30,000 network malfunctions in Japan each year (The Japan Times)
Dave Farber <farber@keio.jp>
Mon, 5 Apr 2021 12:30:51 +0900
https://www.japantimes.co.jp/news/2021/04/04/business/tech/ntt-cosmic-rays/ (https://www.japantimes.co.jp/news/2021/04/04/business/tech/ntt-cosmic-rays/)
https://cdn-japantimes.com/wp-content/uploads/2021/04/np_file_79612.jpeg (https://cdn-japantimes.com/wp-content/uploads/2021/04/np_file_79612.jpeg)
The Japan Times, 4 Apr 2021 (Bloomberg)
Nippon Telegraph and Telephone Corp. has found that cosmic rays are causing an estimated 30,000 to 40,000 temporary malfunctions in domestic network communication devices in Japan every year.
...
https://catless.ncl.ac.uk/Risks/32/60#subj3 (https://catless.ncl.ac.uk/Risks/32/60#subj3)
However telecom systems are designed and implemented with the presumption that errors will occur and bits of the network will disappear without warning.
I don't think it is a No True Scotsman argument to say something like "a properly trained person will never point a firearm at anything or anyone, even when the safety is on, unless they are ready to kill them". This is a simple rule known for as long as firearms have existed; but the firearm itself does not enforce the rule. A lot of people (including soldiers) do not know or neglect to follow that rule, so accidents happen, and people get killed. With C, bugs and security failures occur often because the developers do not care (about making the code secure against unexpected inputs); I've heard countless times that "we don't have the time for that right now; we'll add those in later".
Defects in a "castle built on sand" do not excuse building on sand rather than on rock.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.
Which is also a classic argument in favour of languages that support garbage collectors :)
Doubly so for languages where every developer creates their own reference counting garbage collector.
-
It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.
Applying that to C is fairly easy.
-
It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.
NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.
Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.
-
It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.
NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.
Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.
I think that’s out of necessity. Someone has to write their own “framework” at every C++ house I’ve seen and work to some poorly defined subset of the language which doesn’t have so many foot guns.
Rust is the same. But the academic papers are blog posts and brigading on tech news aggregators.
Similar with Go. It’s that fuzzy joy that Java was (if you avoided J2EE 1.x :) )
-
It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.
NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.
Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.
I think that’s out of necessity. Someone has to write their own “framework” at every C++ house I’ve seen and work to some poorly defined subset of the language which doesn’t have so many foot guns.
One of the notable points about Java was the speed with which a wide range of high quality libraries became available, and which played nicely with each other. C++ had failed to do that in a decade, and is still playing catch up.
Rust is the same. But the academic papers are blog posts and brigading on tech news aggregators.
Similar with Go. It’s that fuzzy joy that Java was (if you avoided J2EE 1.x :) )
I'm ambivalent about Go and Rust, but they have a good starting point in that they've nicked concepts from CSP ;)
I kicked the tyres of J2EE (but not the development environments for it!), looked at Spring, and evaluated a JAIN implementation. For real work in a telecoms server, I/we created a small library that very favourably surprised other engineers and companies.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.
Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.
Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.
As usual it is a case of choosing your poision.
However, given state sponsored and criminal gang sponsored efforts, I'm not sure that it is possible to claim "hackers can't be bothered attacking". The "hack a fishtank thermometer" I mentioned is a good counter example.
-
I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.
Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.
Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.
Nope.
This is one of about 100 different concerns when it comes to information security. The holistic picture is more important than a specific vulnerability. You have to layer your defences because they are not perfect or reliable independently.
Better to have multiple layer mitigation. But keeping that surface area small is vastly important.
In our case there’s a respectable WAF between public and ingress. And no ingress services are written in C.
-
And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.
Again, agreed.
But when the fundamental properties of a language mean that large applications are "castles built on sand", we shouldn't shy away from recognising that choosing a different language ought to mean the "castle is built on rock". It is, of course, possible to choose a different language so that the "castle is built on a swamp".
Fully agreed.
Problem is, every programming language we currently have, have their drawbacks. I "solve" this by using multiple programming languages; for example, Python for UI, C for heavy computation (in a library form). I automate tasks using Bash or POSIX shell scripts, Makefiles, and Awk; the latter is especially useful for certain line/record based format data processing. I try to pick each tool, each programming language, that seems the most appropriate for each task at hand, while being careful to not let my personal preferences skew the choice too much.
Now that Rust has its own foundation, I'm hoping it will become a reasonable alternative to systems level programming. I dislike Go for the same reasons I dislike .Net: being single vendor controlled projects, their future is uncertain; and I've been bitten by single vendor products often enough to be wary of subjecting myself to those if reasonable alternatives exist.
We should distinguish swamps and sand from rock, and choose rock whereever possible.
Absolutely! But, what would be the rock-analog to replace the swamp and sand that is C, in systems programming? (Specifically, efficient low level libraries and services interfaced to from higher level languages, for my own use cases?) I personally do not know of one.
So, I personally am trying to use piling (driving heavy stilts or posts into the swamp and sand to create a stable enough base to build on; an analog for replacing just the standard C library with something better, more suited to the task), until those better than I in computer science can develop a language that can achieve the same or better end results.
(For example, having carefully considered and tested various cases, I've changed my mind regarding garbage collection. I do "like" pool based allocation more, but in objective terms, good garbage collection schemes simply have fewer drawbacks.)
-
Scheme makes a good systems programming language :popcorn: :-DD
As for single vendor controlled products, I've learned that opinionated vendors are a win for solving problems. I've got 20 years out of .Net so far.
-
Scheme makes a good systems programming language :popcorn: :-DD
As for single vendor controlled products, I've learned that opinionated vendors are a win for solving problems. I've got 20 years out of .Net so far.
I thought you made your money clearing up the messes dropped buy other people!
-
And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.
Again, agreed.
But when the fundamental properties of a language mean that large applications are "castles built on sand", we shouldn't shy away from recognising that choosing a different language ought to mean the "castle is built on rock". It is, of course, possible to choose a different language so that the "castle is built on a swamp".
Fully agreed.
Problem is, every programming language we currently have, have their drawbacks. I "solve" this by using multiple programming languages; for example, Python for UI, C for heavy computation (in a library form). I automate tasks using Bash or POSIX shell scripts, Makefiles, and Awk; the latter is especially useful for certain line/record based format data processing. I try to pick each tool, each programming language, that seems the most appropriate for each task at hand, while being careful to not let my personal preferences skew the choice too much.
Yes indeed. Hammers vs screwdrivers and all that. But you can insert screws with hammers.
Now that Rust has its own foundation, I'm hoping it will become a reasonable alternative to systems level programming. I dislike Go for the same reasons I dislike .Net: being single vendor controlled projects, their future is uncertain; and I've been bitten by single vendor products often enough to be wary of subjecting myself to those if reasonable alternatives exist.
We should distinguish swamps and sand from rock, and choose rock whereever possible.
Absolutely! But, what would be the rock-analog to replace the swamp and sand that is C, in systems programming? (Specifically, efficient low level libraries and services interfaced to from higher level languages, for my own use cases?) I personally do not know of one.
Smalltalk, xC, or macro assembler >:D
More reasonably, Ada, SPARK or - if they pan out - Rust or Go.
So, I personally am trying to use piling (driving heavy stilts or posts into the swamp and sand to create a stable enough base to build on; an analog for replacing just the standard C library with something better, more suited to the task), until those better than I in computer science can develop a language that can achieve the same or better end results.
(For example, having carefully considered and tested various cases, I've changed my mind regarding garbage collection. I do "like" pool based allocation more, but in objective terms, good garbage collection schemes simply have fewer drawbacks.)
A good GC implementation has remarkably few drawbacks for soft realtime applications - e.g. telecom networks. And even fewer if you can constrain the programming style so that most data has averyshorlife with limited visibility. That how some fintech people use Java for trading. Mind you,that mob also encode business rules in FPGAs to minimise latency!
-
Scheme makes a good systems programming language :popcorn: :-DD
As for single vendor controlled products, I've learned that opinionated vendors are a win for solving problems. I've got 20 years out of .Net so far.
I thought you made your money clearing up the messes dropped buy other people!
Yes by creating new piles of shit :-DD
-
I'd like to play with a simple OS not written in C/C++.
How much do you consider "a simple OS"?
like DOS with TSR
-
I'd like to play with a simple OS not written in C/C++.
How much do you consider "a simple OS"?
like DOS with TSR
DOS wasn't an operating system, it was a program loader with a few built-in peripheral libraries.
I liked it: load you program and the machine is yours!
-
DOS wasn't an operating system, it was a program loader with a few built-in peripheral libraries.
I liked it: load you program and the machine is yours!
DOS stands for "disk operating system"; DOS + TSR means you can suspend a program, and launch an other.
It's my definition of "simple OS".
Things like "UCOS/2/3" are of a different level (it's a static task RTOS), and also of a different level of complexity. I have already implemented it on a MIPS32 and on arm-classic machine, but I only wrote the specific low level while the 90% of the code was just "ok" out of the box. Then I wrote a couple of tasks and a couple of drivers, one of them was a Modbus driver, the other a driver for a radio-link.
Kind of producer consumer problem. Not do bad, both were nice experiences, but I cannot rewrite this stuff in assembly, and it's too much code for translating it in Ada/Rust/etc...
I need something shorter, simpler.
-
I'm only too we'll aware of what MSDOS was :(
It ran a single programes at a time. You loaded that into memory from cassette, floppy, or if you're luck a hard disk.
If you wanted to do something different, you shut down that programes and loaded another. Hence the famous Small T-shirt slogan, "Don't mode me in"
Years later my u could sort-of run several programs at the same timeusing top view or DESQview.
Terminate and Stay Resident (TSR) was a side issue, usually used to loads few tiny utility programes that made better use of 640k
-
DOS wasn't an operating system, it was a program loader with a few built-in peripheral libraries.
I liked it: load you program and the machine is yours!
DOS stands for "disk operating system"; DOS + TSR means you can suspend a program, and launch an other.
It's my definition of "simple OS".
Things like "UCOS/2/3" are of a different level (it's a static task RTOS), and also of a different level of complexity. I have already implemented it on a MIPS32 and on arm-classic machine, but I only wrote the specific low level while the 90% of the code was just "ok" out of the box. Then I wrote a couple of tasks and a couple of drivers, one of them was a Modbus driver, the other a driver for a radio-link.
Kind of producer consumer problem. Not do bad, both were nice experiences, but I cannot rewrite this stuff in assembly, and it's too much code for translating it in Ada/Rust/etc...
I need something shorter, simpler.
FORTH kernel. Collapse OS is interesting: https://collapseos.org/ (https://collapseos.org/)
Plus you can build some hardware it'll run on!
Also Brad Rodriguez's Moving FORTH series is interesting https://www.bradrodriguez.com/papers/moving1.htm (https://www.bradrodriguez.com/papers/moving1.htm)
FORTH is not a language or an OS or a toolchain. It's just completely different.
-
It ran a single programes at a time.
Yes, that would make it a "single-tasking operating system". Which is why "multi-tasking" is often used to describe other types of operating systems.
You can be as sniffy as you like, but it was what it was: an actual operating system.
If you wanted to do something different, you shut down that programes and loaded another.
Indeed, but the important factor you've missed is that you didn't reboot the machine. DOS was still running, state maintained, etc. During the program run DOS was supplying services. A bootloader doesn't do that.
Hence the famous Small T-shirt slogan, "Don't mode me in"
Apparently not that famous. I had to look it up and found it related to user interface design. I grant that software of that era typically used modes, but that wasn't a DOS issue per se and applied to, well, interfaces of that time. Maybe your memory of that (and of what DOS was/wasn't) could do with a refresh.
---
From Wikipedia (https://en.wikipedia.org/wiki/Larry_Tesler):
Tesler developed the idea of copy and paste functionality and the idea of modeless software.
Also from Wikipedia (https://en.wikipedia.org/wiki/Mode_(user_interface)), linked to above, with my emphasis:
In user interface design, a mode is a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived results different from those that it would in other settings.
-
I'm only too we'll aware of what MSDOS was
I spent 5 years on a DOS machine with Turbo Assembler, Turbo Pascal, Turbo Basic and Turbo C
I learned a lot, then I moved to a UNIX "single user" (yes, incredible) machine: BeOS! Then to Linux.
happy days ... 20? 30? years ago ;D
-
I was barely inflicted with that crap fortunately. A relative died and left me a pile of cash so I got myself a nice Acorn A420 to replace my BBC. Eventually this was replaced with NT while I was using Sun kit at university and work...
MSDOS was horrible horrible horrible yuck. My father built a large business on it selling payroll software.
-
FORTH is not a language or an OS or a toolchain. It's just completely different.
You can say that about Smalltalk or Squeak.
-
I was barely inflicted with that crap fortunately. A relative died and left me a pile of cash so I got myself a nice Acorn A420 to replace my BBC. Eventually this was replaced with NT while I was using Sun kit at university and work...
MSDOS was horrible horrible horrible yuck. My father built a large business on it selling payroll software.
As I recall, dimly, the original Archimedes operating system (Arthur, after Arthur Norman who wrote optimiing compilers amongst other things) was very strange.
MSDOS was a pain, but no worse than its predecessors. Windows was the hack compared to its predecessors.
-
The original Arthur 1.20 was a pretty rough bit of code for sure. Fortunately I only had to suffer it for a year before I managed to persuade someone to do me some RISC OS 2 ROMs.
Rumor has it that it was actually short before A Risc os before THURsday due to failing entirely to ship the original OS plan which was a weird bastardisation of Modula 2 and Mach which may just have taken over the world if they had finished it. Look up ARX https://en.wikipedia.org/wiki/ARX_(operating_system)
Windows 3 was fairly nice at the time. I had all sorts of shit wired up on that doing automated testing with 16-bit VB.
-
Given I was in Cambridge until late 87 and played with the first Archimedes, I may have been using Arthur 0.20.
I never asked Arthur about "his" filesystem :)
-
I started the project two years ago, in my case the filesystem is very advanced, but the heavy job is done remotely.
It's somehow similar to NFS but simpler.
The client, even if it's written in assembly, only has to issue simple requests to the remote server where the core of the filesystem runs
client's requests:
- file_open
- file_close
- file_read{8,16,32}
- file_write{8,16,32}
- file_read_block
- file_write_block
- file_get_size
- file_get_position
- file_set_position
- folder_open
- folder_close
- folder_read
There is not yet any implementation for metadata (when was this file/folder created? who is the owner? last time the file/folder was read? ... the server replies "not yet implemented"). The current implementation runs on a weird MIPS32 board with pipeline disabled. There are no delayed slots and no hazards with registers. It's clocked at 25Mhz, and it's a bit slow, but I like it.
The filesystem uses one serial line at 1Mbps with basically three packets, one for transporting commands and requests, one for receiving feedback, and one for transporting data.
This project is basically a "bootloader" which can mount its filesystem after the bootstrap. The user can list for some folders and files, open a file into a folder and load its content into memory, so if the file is a binary, the bootloader can can also switch into user-mode and jump into what has been loaded.
The code in kernel space can always takes back control if something goes wrong (well, there is no memory protection, so ... if the application writes some pretty garbage into kernel space it will be a dead funeral).
Not bad, useless and it makes no sense but it is funny, and it's written in pure MIPS assembly :D
Anyway, this is not an OS, it's just a bootloader able to talk with a remote filesystem-core.
-
MSDOS was horrible horrible horrible yuck. My father built a large business on it selling payroll software.
Yes it was. However, as a clone of CP/M for the 8086 it allowed a lot of CP/M software to be quickly ported to the new 8086 machines. The sad part about MSDOS is not that it existed, but that it stuck around for so long. It should have had quite a short market window.
-
It was sad that Windows was such a thin layer on top of MSDOS, continuing its limitations plus introducing extra complexity.
-
Yes it was. However, as a clone of CP/M for the 8086 it allowed a lot of CP/M software to be quickly ported to the new 8086 machines. The sad part about MSDOS is not that it existed, but that it stuck around for so long. It should have had quite a short market window.
I'm running Windows 10.
C:\2>echo a>a
C:\2>copy a+a b
a
a
1 file(s) copied.
C:\2>dir
Volume in drive C has no label.
Volume Serial Number is 148E-1AFC
Directory of C:\2
04/19/2021 07:18 PM <DIR> .
04/19/2021 07:18 PM <DIR> ..
04/19/2021 07:18 PM 3 a
04/19/2021 07:18 PM 7 b
2 File(s) 10 bytes
So why is the file "a" three bytes? CP/M of course (CR-LF)
Why is the file "b" seven bytes? CP/M of course. Have to add that CP/M end of file character.
Windows/DOS (from QDOS, Quick and Dirty OS), a hack on top of a hack on top of a hack.
-
... Jeez, you lot don't half have tea-stain-tinted spectacles! ...
I liked DOS. You could have it on a floppy with enough space left to do other things. I didn't like or use Windows until 95. I got alot of milage out of DOS with QuickBASIC then later QuickC. For $99, those programs were a great bang for the buck in my opinion.
-
... Jeez, you lot don't half have tea-stain-tinted spectacles! ...
I liked DOS. You could have it on a floppy with enough space left to do other things. I didn't like or use Windows until 95. I got alot of milage out of DOS with QuickBASIC then later QuickC. For $99, those programs were a great bang for the buck in my opinion.
Windows 95 was literally an application that ran on top of DOS and you retained the ability to do native DOS command line stuff. Ditto for Windows 98. Also Windows ME. All the later Windows versions originate from 32-bit Windows NT line, which has evolved to the 64-bit Windows of today.
-
>> How much do you consider "a simple OS"?
like DOS with TSR
Well, that's why I asked. DOS implemented a filesystem and a bunch of utilities, but had no multi-tasking and not much in the way of device drivers.A bunch of the current "RTOS" implementations give you real-time and multitasking, but no file system, utilities, or program loading capability.
Windows 95 was literally an application that ran on top of DOS and you retained the ability to do native DOS command line stuff.
Meh. Since we admitted that DOS was little more than a program loader, it's not clear what the difference is between "an application loaded by DOS" and "an operating system loaded by a bootloader."
-
Yes windows 95 was not sitting on top of DOS at all. Neither was windows 3.1 really. It was more a full hardware context switch to another inferior kernel :-DD.
Edit: in fact there was an undocumented native loader for it which was based on NTLDR. This shipped in windows ME if I remember but was never enabled. You can boot it directly with NTLDR anyway.
-
I liked DOS. You could have it on a floppy with enough space left to do other things. I didn't like or use Windows until 95. I got alot of milage out of DOS with QuickBASIC then later QuickC. For $99, those programs were a great bang for the buck in my opinion.
When I moved to Linux, I was less impressed and less shocked compared to the experience from DOS to BeOS.
I had a shock when I left DOS for BeOS, because suddenly everything was different :o :o :o
At that time I was used to installing everything by hands on a primitive i486 machine where you need to install a card and a driver, for each device.
For example, the CDROM was not ATAPI-IDE or SCSI, it was a proprietary Creative thing for which you needed to install an ISA16 card and a couple of drivers and also edit the "config.sys" file to tell the operating system how to configure them.
The same applied to the network card, there were just a few NICs supported by DOS, mostly by 3COM You had to manually setup IRQ, DMA, and edit the "config.sys" accordingly.
When I moved to BeOS v5 I found no floppy disk but only a bootable CDROM. WOW it was a new for me, I hadn't never seen before an OS you can install from a CDROM.
Until then my era experience with DOS had been three floppy disks for the core of the OS plus nine for misc(1), and a couple of days for the setup, especially to make some utilities able to "suspend" and "resume" by TSR. It was a crude set of hacks.
Then I moved from a 486 to a PentiumII, BeOS was already ready to have multitasking, audio and video support already built-in, networking capabilities with just a couple of hacks.
BeOS v5.01 didn't naively support networking, I had to install an add-on called "net-bone", which basically added utilities like "telnet, fpt, finger, ..." and later also "scp ssh".
I also installed a C compiler package, gcc-v2.95, which I used to develop my applications and tools. This was completely different from the experience with Borland Turbo C. Different compilers, different libraries, different dialects (Borland vs GNU), different workflow, different debugging workflow (IDE debug vs GDB), different cost (90 Euro as "student pack" vs opensource).
Years later, I don't remember it as a bad experience, it was just a different experience, and even the Linux experience (kernel v2.2 and v2.4 at the time) is different from what we have today (kernel v5) ;D
(1)
- Norton Utilities
- Procomm (like Minicom on Linux)
- Borland' compilers { Basic, Pascal, C } (90 euro each, as "student pack")
- driver for a pretty nice serial (RS232) trackball mouse
- driver for the CDROM, not ATAPI, it was Creative's proprietary interface provided by the SoundCard
- driver for the sound-card Creative SoundBlaster16
- driver for 3COM network card
- Microsoft Lan suite with TCP/IP and UDP/IP tools and libraries
9 floppy disks for these, paid 400 euro for this!
-
Well, that's why I asked. DOS implemented a filesystem and a bunch of utilities, but had no multi-tasking and not much in the way of device drivers.A bunch of the current "RTOS" implementations give you real-time and multitasking, but no file system, utilities, or program loading capability.
I can easily add my "serial file system" to UCSO/2/3, it would just be a task with simple primitives, but the core of the RTOS itself is really too much code for me.
Years ago I wrote a minimal skeleton for a RTOS. I wrote it for the GBA (arm classic), never really completed, never used, but I can resume the project since it's less than 1K lines of C
Why do I remember it's less than 1K lines of C? Nowadays you can use Gcc for everything, years ago compiling Gcc was not as easy as it's today, and I was less skilled, so I remember I used a demo commercial C compiler that is limited to 1K lines for each C module, but since I was very lazy at that time, I didn't make "modules" (to be compiled singularly and then linked together) but rather only one big module with a lot of #include "file.inc" :D
Oh, not bad, at least it helped make the skeleton the smallest possible ;D
-
Well, that's why I asked. DOS implemented a filesystem and a bunch of utilities, but had no multi-tasking and not much in the way of device drivers.A bunch of the current "RTOS" implementations give you real-time and multitasking, but no file system, utilities, or program loading capability.
Digital Research did expand CP/M to MP/M and added multiprogramming. I never used it because I was focused on a single user environment. I ran the programs I wanted and if somebody else wanted to run something, well, they could buy their own computer.
I still remember when a 4kx8 static RAM board cost $400 and it would take 16 of them ($6400) to fully populate the memory space of a 8080. Of course you couldn't actually get that many boards inside an Altair 8800 and if you did do that, somehow, the power dissipation would be enormous.
-
Interesting reading. I haven't written any higher language code for many years. I play with microprocessors and use assembler, because I want exact control over what is going on. Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp.
When I first started writing HLL the choices were COBOL or FORTRAN. Some programs were written with segments in both with a bit of assembler thrown in. I think once one gets away from the hardware, any language can be butchered to do anything. I taught assembler to a class, gave them a disassembler written in COBOL that disassembled itself. It took a while for them to get their heads around, then they would modify the source to see what the COBOL compiler did.
All programming is a compromise between competing requirements - efficiency, portability, maintenance, security, development time, learning time. Favouring one language over another can just be due to the application and have little to do with the benefits of the language. So you want a job programming web sites - knowing Forth, C or Rust isn't going to get far - PHP, javascript, CSS and HTML, even though they are not very useful generally, will do the job. Banks use COBOL, meteorologists (I believe) use a variant of FORTRAN. I think C is popular for operating systems because to some extent it is portable, has a pool of practitioners, and introduced the pointer variable that allows all sorts of efficient manipulation. I have tried to come to grips with the C variants for microprocessors, they bend so much to accommodate the particular processor they aren't that portable. The libraries are inscrutable, maybe they work, maybe they fit. So I am not a fan.
All of which is completely off topic. I was going to mention implementing security via hardware, where only a small amount of well tested code is given full privilege, and most code is run at lower security levels (VAX VMS comes to mind). But it is late and I'm going to bed.
-
Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp
Which CPU are you using for this? :D
-
Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp
Which CPU are you using for this? :D
PIC16F1455. 10MHz external clock, internal x4 PLL for internal clock, = 10MHz instruction time.
-
Interesting reading. I haven't written any higher language code for many years. I play with microprocessors and use assembler, because I want exact control over what is going on. Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp....
Completely off topic...
I too code microprocessors (usually AVRs lately) mostily in C, sometimes in assembler. I have no idea how to do multi threading. I only do very simple stuff with microcontrollers. I completely don't understand OOP. If I Google to find a function I want and it ends out being in C++, I'll figure out how to convert it to a C function.
That said, I found out 30 years ago that I had a misperception regarding assembler and speed. I transitioned from QuickBASIC to QuickC because I believed that C was faster than BASIC. And with C, I could include inline assembly (best of both worlds). My first incentive to do this involved reading RSSI values that were in dB and computing averages quickly for a TDM power control system (dB->watts->avg). C and assembler allowed me to do this. No doubt, assembler is going to be the fastest, but... it's amazing how fast code can be if it's written well in C. I discovered that the reason my QuickBASIC code was usually slower is because I didn't define the variables up-front, and the default was floating point. If I defined variables as int, QuickBASIC wasn't slow (compiled BASIC). It was comparable to QuickC. (this was early 90's I think).
My present day HLLs are C and LabVIEW. LabVIEW runs like compiled C, but since it (I think) does some parallelizing for you (if you have multiple processors) it is amazingly fast (if you code well). A while back I wrote an OFDM vector signal analyzer in LabVIEW. I had a receiver streaming in I/Q baseband samples over TCP at 1.625 Msps. Our TDM system had a 10msec uplink, 10 msec downlink. With a 128 point FFT and 16 point CP you get about 116 symbols in a 10msec frame. The LabVIEW program would use cross correlation to find the preample, do a frequency estimation based on training symbols in the waveform, correct the data for frequency offset, equalize, demodulate, compute EVM, display whatever you wanted to look at (individual symbols, multiple symbols). I think it was 108 active carriers out of a 128 point FFT. Carriers could be BPSK, QPSK... up to 1024 QAM. And the program on a quad core Lenovo laptop kept up in real time! It could do all the computation and presentation of the signal before the next TDM frame came. I had not had any expectation that the program would keep up in real time. I was doing the work because we were looking to remove the pilots from our waveform, and Keysight's VSA (what we were using at the time to analyzer our signals) choked on that.
-
That said, I found out 30 years ago that I had a misperception regarding assembler and speed. I transitioned from QuickBASIC to QuickC because I believed that C was faster than BASIC. And with C, I could include inline assembly (best of both worlds).
That depends entirely on:
1) whether the CPU was designed for running compiled languages such as Pascal or C. 6502 and z80 definitely weren't, but AVR was. 8086 and 68000 weren't really but are kind of OK, but not really. 6809 was a bit later and is pretty good for an 8-bitter. Anything from MIPS and ARM and on is designed for running compiled languages and you have to work very very hard to beat the compiler.
2) how good you are at assembly language and working around and exploiting the weirdness of your CPU. Especially on 6502 and Z80 and the like. But early x86 too.
Something like LabView presents you with a high level language, but the people who wrote it made all those FFTs and so forth in assembly language, or something very close to it.
-
8086 and 68000 weren't really but are kind of OK, but not really.
I remember reading many years ago that the 8086 segmented memory architecture was a natural match for Pascal, easing the job of the complier:
- The code segment is used for instructions
- The data segment holds global variables
- The stack segment holds return addresses and local variables
- The extra segment holds variables accessed via pointers (IIRC, in old standard Pascal pointers are not free to point to any variable, only to variables allocated with New()
Of course, those were times when 64 kB per each segment was a respectable size...
-
8086 and 68000 weren't really but are kind of OK, but not really.
I remember reading many years ago that the 8086 segmented memory architecture was a natural match for Pascal, easing the job of the complier:
- The code segment is used for instructions
- The data segment holds global variables
- The stack segment holds return addresses and local variables
- The extra segment holds variables accessed via pointers (IIRC, in old standard Pascal pointers are not free to point to any variable, only to variables allocated with New()
Of course, those were times when 64 kB per each segment was a respectable size...
Right.
Yeah, it's simply untenable on a small machine for C where address arithmetic is standard and frequent, forcing every pointer to 32 bits segment:offset. It's not too bad for Pascal where you don't do arithmetic on pointers and a pointer can be just the segment number. The pain comes because there's only one extra segment so you have to keep reloading it to switch between objects, and that was slow (maybe not on original 8086). Pretty soon 64k got to be too small for array or big buffers for many programs. Even when you has only 1 MB you might want to do some scientific calculation using more than 64k for one array.
68000 had a similar problem in that there was only a 16x16 multiply instruction. Both MPW and THINK Pascal only took a 16 bit result from that, so array sizes were also limited to 64k there. I don't know why they did that when the MULU/MULS instructions *always* produced a 32 bit result.
At one point I got Rich Siegel to fix this from his personal copy of the THINK Pascal source code and send me the resulting compiler. This made things much much better as then you could have up to 64k elements of up to 64k bytes each. I may be the only person in the world who ever had a copy of this version of the compiler.
-
1) whether the CPU was designed for running compiled languages such as Pascal or C. 6502 and z80 definitely weren't, but AVR was. 8086 and 68000 weren't really but are kind of OK, but not really. 6809 was a bit later and is pretty good for an 8-bitter. Anything from MIPS and ARM and on is designed for running compiled languages and you have to work very very hard to beat the compiler.
The z80 was fine for C, inasmuch as it was fine for anything. But the IX,IY registers were surprisingly limited for most things. All the z80s bolt-on warts goodies made me appreciate the risc-like simplicity of the 8080 :)
The key point about C is that it assumes the memory model is a single uniform address space where a each byte is uniquely addressable. That matches the 6800/9, 8080/8085, 68k, but not the 1802, 6502 and especially not the 8086/8.
Remember the horrors of determining whether two segment+offset 8086 pointers referred to the same object, and all the horrible grotty workarounds to try to make it less grossly inefficient? Shudder.
-
Oh I'd forgotten about that. Thanks for the headache. Going to dream about FP_ macros and far pointers tonight now >:(
I inherited someone's code once and they didn't understand it when they wrote it. That was not much fun. After about a week of banging my head on it I actually rewrote the whole damn thing in VB for MSDOS which took less time than unfecking it. As a bonus that hid the problems away.
-
The key point about C is that it assumes the memory model is a single uniform address space where a each byte is uniquely addressable. That matches the 6800/9, 8080/8085, 68k, but not the 1802, 6502 and especially not the 8086/8.
6502 address space is fine. 64 Kib, flat.
Unless you've plugged an expansion card in that gives you a MB or two of RAM in banks of .. 4K? 16K? I don't know, I never used one.
The problem with 6502 is when you feel as if it's got no registers. Until you realise you should treat Zero Page as the real registers, at which point you've got a zillion of them. Dedicate a couple of ZP bytes as a User Stack Pointer, then partition a bunch more in the same way as PowerPC, Aarch64, RISC-V etc have 8 or 10 registers for arguments/locals/temps, a dozen or so for callee-save variables, and a few for temps that no one owns. If you allocate them as 16 bit pseudo registers then you've probably only dedicated around 64 bytes so far, leaving 192 for goodness knows what. Then use the same kind of calling convention as the above RISCs with arguments and return value in the caller-save registers. If you need to use some callee-save registers then copy them en-mass to the User stack at the start of your function (use a subroutine for this) and copy them back just before you return. You may as well use the hardware stack for function return addresses -- unless you're planning to recurse more than 128 levels deep (unlikely) -- but basically nothing else.
You can make some very pleasant 2-address 16 bit (or 32 bit) arithmetic routines where you load the dst ZP register number into X and the src ZP location into Y and then call a function.
add16:
clc
lda $00,X
adc $0000,Y
sta $00,X
lda $01,X
adc $0001,Y
sta $00,X
rts
Twice (or more) as compact to call as to use inline code, and about 60% of the speed (more for 32 bit functions)
ldy #src ; might already be correct, so can often be omitted
ldx #dst ; might already be correct, so can often be omitted
jsr add16
Not quite as compact as SWEET16 or USCD P-system etc bytecode (but not far off), but ~5 times faster.
-
6502 is flat, and - despite never having used one for more than a 30byte demo program - I'm sure you are right about regarding zero page as all registers.
However, ISTR there not being any instructions that operated on 16-bit offsets/pointers - you had to synthesise them every time you wanted them. The 6800 was much better in that respect with IX and IY.
As for 256 registers, I'm unconvinced of their utility for HLLs of the time which couldn't do very much global register optimisation. The amd29000 also had vast numbers of registers (?192?), but they weren't easy for a compiler to use effectively.
OTOH, I can easily see how an interpreter could make use of 256 "special purpose" registers.
I've always said that computers (and their programmers) are like crows. Their counting ability is 0-1-many, since other numbers are too difficult to deal with :)
-
Best use for zero page on the 6502 is stack as it’s cheaper to access it. I think ARM started as 32 bit 6502 with orthogonal register utility. Apart from the bastard 26 bit PC/flags that cursed the first few chunks of silicon.
Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.
-
Best use for zero page on the 6502 is stack as it’s cheaper to access it. I think ARM started as 32 bit 6502 with orthogonal register utility. Apart from the bastard 26 bit PC/flags that cursed the first few chunks of silicon.
Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.
Roger Wilson and Steve Furber were indeed heavily influenced by the 6502 when creating ARM1. I've never really understood how, because the ARM1 always felt as clean as the PDP11 vision.
But back when 6502/z80/8086 were new and interesting, C compilers were so primitive they still took note of the "register" keyword! (Now the problem is they are so damn complex that very few people can predict what strange "bugs" they will generate with higher optimisation level.
(C lawyers and purists will, arguably correctly, state that the "bugs" are programmer errors. I tend to regard them as language committee specification errors :) )
-
I think the ARM1 was mostly clean because it was new and minimalist. Newer ARM cores are somewhat more raggedy.
As for optimisers, that's mostly GCC which turns out rubbish to be fair. I haven't noticed clang do anything quite as terrible at high optimisation levels. I think my favourite one was GCC unrolling a variable cycle loop. Not sure how it worked out that was possible :-//
I am on the fence with respect to "bugs". Some are programming errors, some are language specification error but the majority in experience are actually not understanding the task that is required to start with to a sufficient degree and winging it hoping that if the problem is solvable that you do enough of it to get paid.
-
Best use for zero page on the 6502 is stack as it’s cheaper to access it.
Ahhh .. I'd contest that.
Ok, you could use X as a kind of stack pointer into zero page and do a PUSH A as "STA $00,X; DEX" and POP A as "INX; LDA $00,X". But those are both 4 + 2 = 6 cycles while the actual PHA is 3 cycles and PLA is 4 cycles. Plus you're using 3 bytes of code instead of 1. And you lose a scarce register! Hard to see the point.
The *only* advantage is you can use LDA $01,X STA $02,X etc to directly access stack elements other than the top one, which you can't do with the real stack.
But with the real stack you can do TSX then LDA $0100,X or STA $0101,X etc if and when needed as a cost of 2 cycles for the TSX and 4 cycles for loads or 5 for stores -- the same timing as for Zero Page for loads, and 1 cycle more for stores.
I think ARM started as 32 bit 6502 with orthogonal register utility.
Not at all. The ways in which 6502 influenced ARM are well documented as:
1) the 6502 uses basically every available bus cycle. You can mostly understand the execution time of programs as being the number of bytes of instruction fetch, loads, and stores they do, with just a couple of exceptions (2 cycle minimum, and extra cycle for indexed addressing modes that need a carry from low byte to hight byte)
2) Wilson and Furber visited the Western Design Center to discuss them designing a 32 bit chip for Acorn. The WDC weren't interested, but the Acorn people were stunned at how few employees there were and figured that if WDC could design CPUs then so could they.
Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.
I disagree with that too :-) But then I'm spending quite a lot of my time helping design and evaluate RISC-V ISA extensions.
Certainly it's very useful to use the machine to help you sift through existing code looking for improvement opportunities and evaluating the magnitude of them, rather than just going off hunches, but there's still a heck of a lot of good taste involved.
-
Some of the best (or worst) 6502 code I saw was the BASIC interpreter - 8kbyte of spaghetti (I didn't see the source, just disassembled it). Amazing that it packed all the functions in, dynamic strings etc. I had the interesting task of implementing a sliding windows error correcting protocol (X.PC) on a C64. It had to play nicely with the BASIC because the application was written in BASIC. It was possible to disable the BASIC ROM and access the 8K of RAM that occupied the same address space. So most of the code and buffers were 'invisible'. The O/S had to be hacked also, to implement a bit bashing 1200 baud software UART (the C64 doesn't have one).
I agree that ARM architecture is better handled by HLL.
Multithreading on a processor is pretty straightforward. When a process is interrupted, some of the state has to be saved so it can resume without corruption. If the interrupt moves that state somewhere, it can then enable interrupts and be interrupted itself. It just has to put back the state of the interrupted process on completion and return. I am using the technique to deal with NMEA messages from a GPS module. There is a background process that does some calculation every second, and an interrupt routine to buffer incoming NMEA characters as each character is received. When a full NMEA message is buffered, the character receiver saves the state of the background, branches to the message handler and enables interrupts. That allows the message to be parsed while another buffer is being received. After parsing, the background process state is put back and the parser returns. The background process eventually picks up the parsed data. There is a timing issue that the parser has to complete parsing a message before the next buffer is filled. In real life there's plenty of cycles to spare.
I wanted to run the PIC16F1455 from a precise voltage. The MAX6350 provides 5V up to 15mA, stable to 4uV/C. Wondered if that was enough. Measured the processor current, up to 5mA at times. Cheering.
-
I love linear addressing. Seriously, I love it!
I am playing with two 8bit MPUs attached to a shared ram. 2Kbyte of dual port ram, 32Kbyte of ram, 8Kbyte of rom.
This toy needs a kernel, a pico kernel, a femto kernel, even only a simply scheduler, something to sort out a very wild parallel computing.
Each node runs four tasks cooperative scheduled, the node-A is a producer, the node-B is a consumer, and the dual-port between them is what they use to communicate, push, and pop data.
I am still programming everything in assembly.