any examples of OS not written in C/C++? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: January 11, 2021, 09:29:11 pm
content: 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 newThe 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?

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: January 11, 2021, 09:35:34 pm
content: TempleOS, obviously (HolyCand 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/360was written in pure assembly, because in those days,men were real men.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 11, 2021, 09:51:37 pm
content: 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.

author: DC1MC
author_rank: Super Contributor
timestamp: January 11, 2021, 09:53:26 pm
content: http://menuetos.net/- Pure AssemblyOne can't write an OS in garbagecollectedlanguages, 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"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 withimport 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

author: DiTBho
author_rank: Super Contributor
timestamp: January 11, 2021, 10:35:40 pm
content: thanks guy!any publicly available source?

author: DiTBho
author_rank: Super Contributor
timestamp: January 11, 2021, 10:50:47 pm
content: Quote from: DC1MC on January 11, 2021, 09:53:26 pmWow, crazy, but coolQuote from: DC1MC on January 11, 2021, 09:53:26 pmUmm, 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

author: coppice
author_rank: Super Contributor
timestamp: January 11, 2021, 10:58:33 pm
content: Very few OSes have been written in C or C++, but most of the ones which have survived until now are. There were alotof OSes developed before C existed, and a lot more were developed before C++ existed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 11, 2021, 11:27:32 pm
content: Quote from: DiTBho on January 11, 2021, 10:35:40 pmI 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.htmlOberon:http://www.projectoberon.com/

author: fanOfeeDIY
author_rank: Unknown
timestamp: January 12, 2021, 12:03:50 am
content: 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

author: Cerebus
author_rank: Super Contributor
timestamp: January 12, 2021, 02:32:29 am
content: 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/MulticsMCP - various proprietary Algol variants -https://en.wikipedia.org/wiki/Burroughs_MCPCTOS - PL/M -https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_SystemTOPS-10 - BLISS -https://en.wikipedia.org/wiki/TOPS-10PERQ - Pascal -https://en.wikipedia.org/wiki/PERQPR1MOS - PL/P, SPL both proprietary PL/1 variants -https://en.wikipedia.org/wiki/PRIMOSEricsson AXE(et. al)OS (telephone switch/exchange) - PLEX/SDLNortel DMS-100 telephone switch OS - PROTEL -https://en.wikipedia.org/wiki/ProtelCommercial systems that I've no personal direct experience of:ICL VME 2900 - S3 a proprietary Algol 68 variant -https://en.wikipedia.org/wiki/ICL_VMEXerox Star - MESAIBM System/38 - PL/S another PL/1 variantResearch/Educational systems:Cambridge CAP - Algol68CTSS (MIT) - MAD an Algol variant

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: January 12, 2021, 02:57:28 am
content: 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.

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: January 12, 2021, 03:21:57 am
content: OpenFirmware was written in Forth.

author: coppice
author_rank: Super Contributor
timestamp: January 12, 2021, 02:23:51 pm
content: Quote from: Cerebus on January 12, 2021, 02:32:29 amVMS 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.

author: dave j
author_rank: Regular Contributor
timestamp: January 12, 2021, 04:21:40 pm
content: Quote from: SiliconWizard on January 11, 2021, 09:51:37 pmThat's my, rather vague and dim, recollection too.TRIPOSwas 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.@DC1MCOne 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.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: January 12, 2021, 05:06:22 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 12, 2021, 05:16:31 pm
content: Quote from: dave j on January 12, 2021, 04:21:40 pmYep. 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.

author: DiTBho
author_rank: Super Contributor
timestamp: January 12, 2021, 05:39:25 pm
content: Quote from: dave j on January 12, 2021, 04:21:40 pmThat's why I have invested money and I am investing time to learn it

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 12, 2021, 05:46:57 pm
content: Quote from: NivagSwerdna on January 12, 2021, 05:06:22 pmOh, 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

author: coppice
author_rank: Super Contributor
timestamp: January 12, 2021, 05:47:26 pm
content: Quote from: SiliconWizard on January 12, 2021, 05:16:31 pmBy the early 80s C was a big deal all over the computing world.

author: DC1MC
author_rank: Super Contributor
timestamp: January 12, 2021, 05:49:06 pm
content: 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: January 12, 2021, 06:41:02 pm
content: 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.

author: ve7xen
author_rank: Super Contributor
timestamp: January 12, 2021, 07:01:31 pm
content: Quote from: DC1MC on January 12, 2021, 05:49:06 pmDo 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.

author: coppice
author_rank: Super Contributor
timestamp: January 12, 2021, 07:48:31 pm
content: Quote from: ve7xen on January 12, 2021, 07:01:31 pmAre 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 12, 2021, 07:52:13 pm
content: Quote from: DC1MC on January 12, 2021, 05:49:06 pmTry 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.

author: dave j
author_rank: Regular Contributor
timestamp: January 12, 2021, 08:20:40 pm
content: Quote from: coppice on January 12, 2021, 07:48:31 pmWhilst 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.

author: DiTBho
author_rank: Super Contributor
timestamp: January 12, 2021, 08:44:49 pm
content: Quote from: techman-001 on January 12, 2021, 07:52:13 pmDo 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 12, 2021, 09:02:50 pm
content: Quote from: DiTBho on January 12, 2021, 08:44:49 pmLearning something new is almost always worth it.Now whether you will personally ever use OCaml for anything useful is another question.

author: ve7xen
author_rank: Super Contributor
timestamp: January 12, 2021, 09:26:20 pm
content: Quote from: coppice on January 12, 2021, 07:48:31 pmI 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.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.

author: ejeffrey
author_rank: Super Contributor
timestamp: January 12, 2021, 09:58:48 pm
content: Quote from: DC1MC on January 11, 2021, 09:53:26 pmThat 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.

author: DC1MC
author_rank: Super Contributor
timestamp: January 12, 2021, 10:39:30 pm
content: 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

author: coppice
author_rank: Super Contributor
timestamp: January 12, 2021, 10:45:28 pm
content: Quote from: DiTBho on January 12, 2021, 08:44:49 pmI 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

author: Cerebus
author_rank: Super Contributor
timestamp: January 12, 2021, 10:55:54 pm
content: Quote from: DC1MC on January 12, 2021, 10:39:30 pmYou started off by insulting a wholeclassof people, so I don't think it very appropriate of you to lay claim to the moral high ground.Quote from: DC1MC on January 12, 2021, 05:49:06 pm

author: Cerebus
author_rank: Super Contributor
timestamp: January 12, 2021, 10:56:54 pm
content: Quote from: coppice on January 12, 2021, 10:45:28 pmBut Lisp may be taking things too far.

author: coppice
author_rank: Super Contributor
timestamp: January 12, 2021, 11:01:43 pm
content: Quote from: Cerebus on January 12, 2021, 10:56:54 pmWell, I'd list LISP as one of the interesting things to learn, but I'd put it in brackets.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 12, 2021, 11:07:40 pm
content: Quote from: coppice on January 12, 2021, 11:01:43 pm(why (would (you (say that))))

author: magic
author_rank: Super Contributor
timestamp: January 12, 2021, 11:29:42 pm
content: Quote from: dave j on January 12, 2021, 08:20:40 pmThe Reg got it backwards - for this to happen, Rust would have to gain acceptance of Linux developers, not Linux gain acceptance of Rust developersQuote from: DiTBho on January 12, 2021, 08:44:49 pmNot necessarily, it will also be okay if you learn Standard ML instead.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2021, 12:03:04 am
content: Quote from: magic on January 12, 2021, 11:29:42 pmWell, 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++.

author: magic
author_rank: Super Contributor
timestamp: January 13, 2021, 12:48:49 am
content: 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 itSome guys at some Polish university even put Haskell in there, whatever floats your boat.

author: DiTBho
author_rank: Super Contributor
timestamp: January 13, 2021, 06:45:53 am
content: Quote from: magic on January 12, 2021, 11:29:42 pmLOLwell .. 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 13, 2021, 07:28:21 am
content: Quote from: DiTBho on January 11, 2021, 09:29:11 pmYou 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/staaplrust-forth-compiler 0.5.3https://docs.rs/crate/rust-forth-compiler/0.5.3Firth, A simple Forth-like language intended for DSL creation, implemented in Lua.https://github.com/IonoclastBrigham/firthpyforth, A minimal implementation of the FORTH language, written in Python.https://github.com/whaleygeek/pyforth

author: Nusa
author_rank: Super Contributor
timestamp: January 13, 2021, 08:08:44 am
content: https://github.com/microsoft/MS-DOS

author: radiogeek381
author_rank: Regular Contributor
timestamp: January 13, 2021, 02:20:19 pm
content: Re: VMS and BLISSMy 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*.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2021, 03:14:47 pm
content: Quote from: DiTBho on January 13, 2021, 06:45:53 amThis is a *major* issue indeed.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 13, 2021, 03:20:36 pm
content: Quote from: SiliconWizard on January 13, 2021, 12:03:04 amAs 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 issimple 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.

author: coppice
author_rank: Super Contributor
timestamp: January 13, 2021, 03:53:25 pm
content: Quote from: radiogeek381 on January 13, 2021, 02:20:19 pmAs 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.

author: coppice
author_rank: Super Contributor
timestamp: January 13, 2021, 03:57:12 pm
content: Quote from: SiliconWizard on January 13, 2021, 03:14:47 pmThis 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++.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2021, 04:31:35 pm
content: Quote from: coppice on January 13, 2021, 03:57:12 pmApart 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.

author: westfw
author_rank: Super Contributor
timestamp: January 14, 2021, 03:37:15 am
content: Quotehttps://en.wikipedia.org/wiki/TOPS-10I'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.

author: tooki
author_rank: Super Contributor
timestamp: April 15, 2021, 09:42:05 pm
content: Quote from: SiliconWizard on January 11, 2021, 09:51:37 pmCorrect. 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.)Fromhttps://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txtQuoteFolklore.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

author: DiTBho
author_rank: Super Contributor
timestamp: April 16, 2021, 09:41:13 am
content: 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(1) there is a free runner 32bit timer and bit compare circuit for this, it needs to be armed and controlled.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 10:26:54 am
content: Quote from: DC1MC on January 11, 2021, 09:53:26 pmNot 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. FFIhttp://macintoshgarden.org/apps/apple-smalltalk-80Play with it's modern descendent Squeak, which has the interesting feature that the VM itself (including GC) is written in Smalltalk. FFIhttps://dl.acm.org/doi/10.1145/3281287.3281295

author: janoc
author_rank: Super Contributor
timestamp: April 16, 2021, 10:38:47 am
content: Quote from: DC1MC on January 11, 2021, 09:53:26 pmSorry dude:https://en.wikipedia.org/wiki/Lisp_machineIt 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.

author: thinkfat
author_rank: Unknown
timestamp: April 16, 2021, 12:21:01 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 16, 2021, 12:51:26 pm
content: Quote from: thinkfat on April 16, 2021, 12:21:01 pmOSes 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.

author: janoc
author_rank: Super Contributor
timestamp: April 16, 2021, 01:13:59 pm
content: Quote from: brucehoult on April 16, 2021, 12:51:26 pmThat's just false.https://en.wikipedia.org/wiki/History_of_operating_systemsQuoteThat 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:- Pilothttps://en.wikipedia.org/wiki/Pilot_(operating_system) (writen in Mesa)- Forth has been (and still is) used on bare hardware as a rudimentary OSProbably 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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 16, 2021, 02:16:27 pm
content: Quote from: brucehoult on April 16, 2021, 12:51:26 pm*Cough* Multics. *Cough*

author: janoc
author_rank: Super Contributor
timestamp: April 16, 2021, 02:56:11 pm
content: Quote from: Cerebus on April 16, 2021, 02:16:27 pmMultics is not a good counter-example to his claim. Parts of it were written in PL/I but a large part was in assembly.

author: madires
author_rank: Super Contributor
timestamp: April 16, 2021, 03:08:23 pm
content: Quote from: dave j on January 12, 2021, 04:21:40 pmEarly AmigaDOS was also written in BCPL, and later versions still included some remnants.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 16, 2021, 03:11:19 pm
content: Quote from: tggzzz on April 16, 2021, 10:26:54 amYep. 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 16, 2021, 03:11:54 pm
content: 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 thatgeneral purpose computersand Windows killed their proprietary abomination because of M$ monopoly, 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 16, 2021, 03:13:06 pm
content: Quote from: thinkfat on April 16, 2021, 12:21:01 pmDo you have any reference to back up that claim?

author: madires
author_rank: Super Contributor
timestamp: April 16, 2021, 03:34:03 pm
content: Amiga ROM Kernel Reference Manual series.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 03:46:45 pm
content: Quote from: DC1MC on April 16, 2021, 03:11:54 pmThat'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.

author: dave j
author_rank: Regular Contributor
timestamp: April 16, 2021, 03:48:14 pm
content: Quote from: SiliconWizard on April 16, 2021, 03:13:06 pmThe 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. Seethe Wikipedia page on AmigaOS for more details.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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 03:53:20 pm
content: Quote from: DC1MC on April 16, 2021, 03:11:54 pmNowadays 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 16, 2021, 04:03:38 pm
content: Quote from: tggzzz on April 16, 2021, 03:53:20 pmin my opinion, that's because in modern projects (softcore and researching) they don't have dreams, they have commercial goals ...

author: DiTBho
author_rank: Super Contributor
timestamp: April 16, 2021, 04:06:32 pm
content: OK, it's planned for this weekend a new attempt to write a "scheduler" in assembly.I can do itI can do itI can do itCan I?

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 04:09:49 pm
content: Quote from: DiTBho on April 16, 2021, 04:03:38 pmWhich demonstrates you have zero knowledge of either. Both enable orders of magnitude improvement in different areas - that's why they are interesting.

author: janoc
author_rank: Super Contributor
timestamp: April 16, 2021, 04:11:20 pm
content: Quote from: DC1MC on April 16, 2021, 03:11:54 pmYou mean like that Burroughs mainframe system which is still used to this day?Quote from: DC1MC on April 16, 2021, 03:11:54 pmThen 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?Quote from: DC1MC on April 16, 2021, 03:11:54 pmYeah 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.Quote from: DC1MC on April 16, 2021, 03:11:54 pmSorry 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 04:12:15 pm
content: Quote from: DiTBho on April 16, 2021, 04:06:32 pmA 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

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 04:15:05 pm
content: Quote from: janoc on April 16, 2021, 04:11:20 pmAgreed.The smell of terminal cluelessness or trolling is overwhelming.

author: DC1MC
author_rank: Super Contributor
timestamp: April 16, 2021, 04:19:22 pm
content: Quote from: tggzzz on April 16, 2021, 03:53:20 pmThe 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 offermassiveadvantages 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 16, 2021, 04:24:37 pm
content: Quote from: tggzzz on April 16, 2021, 04:15:05 pmI have to let you know sir, that I'm very cluefull with a terminal, so it may something else...Now, what other wonderful long dead OS was written in a long dead advanced language and what will the future bring us ?

author: coppice
author_rank: Super Contributor
timestamp: April 16, 2021, 04:51:26 pm
content: Quote from: tggzzz on April 16, 2021, 03:53:20 pmI'm not clear what you mean by that. Can you give examples?Quote from: tggzzz on April 16, 2021, 03:53:20 pmThe 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.

author: coppice
author_rank: Super Contributor
timestamp: April 16, 2021, 04:54:05 pm
content: Quote from: DC1MC on April 16, 2021, 04:19:22 pmThe 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.

author: Cerebus
author_rank: Super Contributor
timestamp: April 16, 2021, 05:04:09 pm
content: Quote from: janoc on April 16, 2021, 02:56:11 pmTheoverwhelmingmajority 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.

author: thinkfat
author_rank: Unknown
timestamp: April 16, 2021, 05:06:19 pm
content: 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.

author: thinkfat
author_rank: Unknown
timestamp: April 16, 2021, 05:28:58 pm
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 16, 2021, 05:32:59 pm
content: Quote from: DC1MC on April 16, 2021, 04:19:22 pmTotally agreed!

author: DC1MC
author_rank: Super Contributor
timestamp: April 16, 2021, 05:37:38 pm
content: Quote from: thinkfat on April 16, 2021, 05:06:19 pmClueless 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 16, 2021, 06:03:38 pm
content: 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.pdfFree and OSS advanced (cross)toolchains, even a special one intended forbareboard 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.htmlYou can learn more in this short presentation video:https://rr.noordstar.me/5818b6fa

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 06:35:30 pm
content: Quote from: coppice on April 16, 2021, 04:51:26 pmMany 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.htmlQuoteAkey 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.

author: thinkfat
author_rank: Unknown
timestamp: April 16, 2021, 06:48:48 pm
content: Quote from: DC1MC on April 16, 2021, 05:37:38 pmAs 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 06:56:36 pm
content: Quote from: thinkfat on April 16, 2021, 06:48:48 pmJust so.Plus in my experience the programmers that consider themselves "the elite" oftendon't understand as much as they think about the language. Not quite Dunning Krueger territory, but destructive enoughconcentrate on minutiae and make awful architectural decisions

author: coppice
author_rank: Super Contributor
timestamp: April 16, 2021, 07:04:50 pm
content: Quote from: tggzzz on April 16, 2021, 06:35:30 pmPeople have loved writing "C is bad" articles" since C first appeared, but most don't really hold water.Quote from: tggzzz on April 16, 2021, 06:35:30 pmTinkering with constness is more about the use of ROM than the CPU architecture.Quote from: tggzzz on April 16, 2021, 06:35:30 pmC++ doesn't count. Its so complex and quirky, it certainly does tie people's hands.Quote from: tggzzz on April 16, 2021, 06:35:30 pmI 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.Quote from: tggzzz on April 16, 2021, 06:35:30 pmSure, 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.

author: MarginallyStable
author_rank: Regular Contributor
timestamp: April 16, 2021, 07:09:29 pm
content: 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).

author: coppice
author_rank: Super Contributor
timestamp: April 16, 2021, 07:14:00 pm
content: Quote from: MarginallyStable on April 16, 2021, 07:09:29 pmOne 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 07:34:42 pm
content: Quote from: MarginallyStable on April 16, 2021, 07:09:29 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 07:37:01 pm
content: Quote from: coppice on April 16, 2021, 07:14:00 pmI narrowly missed using CORAL66, and have long been amazed at "name collisions" in C.

author: rstofer
author_rank: Super Contributor
timestamp: April 16, 2021, 07:52:12 pm
content: I don't think I'm going to rush into RustCode:-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.rsLook 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

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 07:54:03 pm
content: Quote from: coppice on April 16, 2021, 07:04:50 pm"90% of everything is crap" - but the 10% is worth understanding.QuoteAbsolutely 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?QuoteNo argument there. If C++ is is the answer, you asked the wrong question.QuoteStrawman question!Untilveryrecently, C didn't even have a memory model. How successful its current memory model will be remains to be seen. It is averydifficult area; even Java had to modify the memory model in the light of experience.QuoteCorrect. There was even an XMOS processor that included an ARM core!Nonetheless, thecombinationof i/o ports, comms fabric, multiprocessor cores, language and IDE tools is unparalleled (ho ho ho). It is theunified visionplusimplementationof 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 07:56:14 pm
content: Quote from: rstofer on April 16, 2021, 07:52:12 pmWise decision; neither am I!QuoteBut microbenchmarks - which might be invalidated tomorrow - are not a good basis for avoiding any language.

author: rstofer
author_rank: Super Contributor
timestamp: April 16, 2021, 08:14:06 pm
content: Quote from: tggzzz on April 16, 2021, 07:56:14 pmBut 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 1959C introduced in 1972C++ introduced in 1985Rust introduced in 2013 - 56 years after Fortran and 41 years after C

author: benst
author_rank: Regular Contributor
timestamp: April 16, 2021, 08:29:48 pm
content: One of my favorites is the Lilith workstation by Niklaus Wirth on which everything was coded in Modula-2 including the OS. Seehttps://en.wikipedia.org/wiki/Lilith_%28computer%29Ben

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 09:24:10 pm
content: Quote from: rstofer on April 16, 2021, 08:14:06 pmYou 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.

author: rstofer
author_rank: Super Contributor
timestamp: April 16, 2021, 10:27:08 pm
content: I just followed the directions using Ubuntu under Win 10. I did no other research.

author: tggzzz
author_rank: Super Contributor
timestamp: April 16, 2021, 10:51:21 pm
content: Quote from: rstofer on April 16, 2021, 10:27:08 pmI 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.Myinexperience 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-Buildhttps://www.phoronix.com/scan.php?page=news_item&px=Rust-Hits-Linux-Nexthttps://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-April-2021-RFC

author: ve7xen
author_rank: Super Contributor
timestamp: April 16, 2021, 11:20:58 pm
content: Quote from: rstofer on April 16, 2021, 07:52:12 pmThe 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.Code:$ rustc main.rs$ du -h main336K main$ rustc -C prefer-dynamic main.rs$ du -h main20K main$ gcc -o main main.c$ du -h main16K main$ gcc -static -o main main.c$ du -h main952K main

author: rstofer
author_rank: Super Contributor
timestamp: April 17, 2021, 02:06:04 am
content: I used these instructions for installation (Section 1.1)https://doc.rust-lang.org/book/ch01-01-installation.htmland this HelloWorld example (Section 1.2)https://doc.rust-lang.org/book/ch01-02-hello-world.htmlI 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?

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 08:13:54 am
content: Quote from: rstofer on April 17, 2021, 02:06:04 amIt appears that your principal objective was to find an excuse to dismiss the language.

author: PlainName
author_rank: Super Contributor
timestamp: April 17, 2021, 08:36:58 am
content: QuoteJust 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'swhat 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).

author: DC1MC
author_rank: Super Contributor
timestamp: April 17, 2021, 08:48:40 am
content: 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.pdfhttps://moscow.sci-hub.se/1864/6e4bd79db1e4753ea76c251441a45133/waldhart1990.pdfThis was what real programmers were doing before CoC and other hipster shite.

author: brucehoult
author_rank: Super Contributor
timestamp: April 17, 2021, 08:57:01 am
content: Quote from: dunkemhigh on April 17, 2021, 08:36:58 amFair 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 bssstatic: 743321 bytes program code, 20876 bytes data, 5984 bytes bssQuoteWith dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.

author: RoV
author_rank: Regular Contributor
timestamp: April 17, 2021, 10:32:20 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 17, 2021, 11:12:47 am
content: 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 valueinput: reg X is the callback to the sensor, method requires index+serviceused services: get_data, get_window_sizewasted registers: D,XThe 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 registerlike if it was a callbackin 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 CNext step, rewriting them as "task" for the scheduler with an additional "sensor fusion" task.

author: DiTBho
author_rank: Super Contributor
timestamp: April 17, 2021, 11:19:07 am
content: 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

author: coppice
author_rank: Super Contributor
timestamp: April 17, 2021, 12:50:13 pm
content: Quote from: tggzzz on April 16, 2021, 07:54:03 pmTry 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 01:14:03 pm
content: Quote from: coppice on April 17, 2021, 12:50:13 pmI 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."

author: brucehoult
author_rank: Super Contributor
timestamp: April 17, 2021, 01:21:33 pm
content: Quote from: DiTBho on April 17, 2021, 11:19:07 amOther 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.

author: Karel
author_rank: Super Contributor
timestamp: April 17, 2021, 01:32:43 pm
content: Quote from: brucehoult on April 17, 2021, 08:57:01 amOnly 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.

author: coppice
author_rank: Super Contributor
timestamp: April 17, 2021, 01:49:02 pm
content: Quote from: Karel on April 17, 2021, 01:32:43 pmRight. 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 02:10:57 pm
content: Quote from: brucehoult on April 17, 2021, 01:21:33 pmReally? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?

author: Karel
author_rank: Super Contributor
timestamp: April 17, 2021, 02:22:36 pm
content: Quote from: coppice on April 17, 2021, 01:49:02 pmThere are people out there that have the opinion that static linking is bad practice but they don't have problems with flatpak or snap...

author: techman-001
author_rank: Frequent Contributor
timestamp: April 17, 2021, 02:32:00 pm
content: According tohttps://www.merriam-webster.coman 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 17, 2021, 02:42:05 pm
content: Quote from: Karel on April 17, 2021, 01:32:43 pmI'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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 17, 2021, 02:45:12 pm
content: Quote from: tggzzz on April 17, 2021, 02:10:57 pmYou 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).

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 03:29:36 pm
content: Quote from: brucehoult on April 17, 2021, 02:45:12 pmI 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_ScotsmanQuoteQ.E.D.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 17, 2021, 05:31:18 pm
content: Quote from: DC1MC on April 17, 2021, 08:48:40 amThere is more recent stuff:https://marte.unican.es/https://m2os.unican.es/

author: madires
author_rank: Super Contributor
timestamp: April 17, 2021, 06:12:14 pm
content: 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 17, 2021, 07:25:05 pm
content: Quote from: tggzzz on April 17, 2021, 03:29:36 pmThat is an unfair statement.Unlike C++, C has two different "modes":hosted environmentandfreestanding 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).

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 09:20:34 pm
content: Quote from: Nominal Animal on April 17, 2021, 07:25:05 pmSo 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.

author: Karel
author_rank: Super Contributor
timestamp: April 17, 2021, 10:54:38 pm
content: Quote from: tggzzz on April 17, 2021, 09:20:34 pmhttps://www.tiobe.com/tiobe-index/

author: tggzzz
author_rank: Super Contributor
timestamp: April 17, 2021, 11:16:37 pm
content: Quote from: Karel on April 17, 2021, 10:54:38 pmTiobe doesn't measure anything useful, let alone something related to the part of the sentence you omitted.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 17, 2021, 11:52:42 pm
content: Quote from: tggzzz on April 17, 2021, 09:20:34 pmNo, 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 optionsI 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.)

author: westfw
author_rank: Super Contributor
timestamp: April 18, 2021, 05:04:58 am
content: QuoteHow 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...

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 09:43:39 am
content: Quote from: Nominal Animal on April 17, 2021, 11:52:42 pmThanks 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...QuoteWhich is unsurprising, since the committee and language conflate the two - to the detriment of both.QuoteI'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.QuoteNot 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...QuoteI 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.QuoteAgreed, 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 insightshttp://archive.adaic.com/projects/atwork/trains.htmlQuotePowerful, but not simple. And the dual nature means it is an unsatisfactory fudge for both.QuoteThose are fundamental and it isfinallybeing recognised that they are critical in multiprocessor systems. And even cheap embedded systems are multicore nowadays.QuoteTechnically perhaps, but practically and commercially not!

author: thinkfat
author_rank: Unknown
timestamp: April 18, 2021, 06:01:32 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: April 18, 2021, 06:12:37 pm
content: Quote from: thinkfat on April 18, 2021, 06:01:32 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 07:38:12 pm
content: Quote from: Nominal Animal on April 17, 2021, 07:25:05 pmIf you believe that, how do you explain the regular exploits like:100 Million More IoT Devices Are Exposedand They Won't Be the Last (WiReD)Gabe Goldberg <gabe@gabegold.com>Wed, 14 Apr 2021 19:41:06 -0400The 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/orACasino Gets Hacked Through a Fish-Tank Thermometer(Entrepeneur)Amos Shapir <amos083@gmail.com>Fri, 16 Apr 2021 17:49:35 +0300Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:https://www.entrepreneur.com/article/368943Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), whicheverybodyshould be reading.Seehttps://catless.ncl.ac.uk/Risks/

author: bd139
author_rank: Super Contributor
timestamp: April 18, 2021, 08:02:37 pm
content: 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 ismemoryregardless 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 08:20:45 pm
content: Quote from: bd139 on April 18, 2021, 08:02:37 pmPrecisely.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.

author: thinkfat
author_rank: Unknown
timestamp: April 18, 2021, 08:23:05 pm
content: Quote from: coppice on April 18, 2021, 06:12:37 pmYes, 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.

author: bd139
author_rank: Super Contributor
timestamp: April 18, 2021, 08:27:58 pm
content: Yep. There's even a competition to see what you can get away withhttp://www.underhanded-c.org/This is a fun one from it:Code:typedef double float_t;

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 18, 2021, 09:16:43 pm
content: Quote from: tggzzz on April 18, 2021, 09:43:39 amI really only object to the No True Scotsman fallacy claim.Quote from: tggzzz on April 18, 2021, 09:43:39 amI 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.)Quote from: bd139 on April 18, 2021, 08:02:37 pmI agree; but I also think it is notnecessaryfor 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.Perfectis the enemy of good.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 18, 2021, 09:41:07 pm
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 18, 2021, 09:42:57 pm
content: Quote from: tggzzz on April 18, 2021, 07:38:12 pmI explain those by pointing out thatpossible ≠ 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.Nothingis 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".

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 09:44:07 pm
content: Quote from: Nominal Animal on April 18, 2021, 09:16:43 pmNot 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 forrepeating (in spades!)the makefile mistake where whitespace is semantically importantthe global interpreter lock, which avoid all sorts of problems at the expense of removing many interesting and useful performance propertiesQuoteI completely agree, unfortunately.QuoteAgain, 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 09:51:54 pm
content: Quote from: SiliconWizard on April 18, 2021, 09:41:07 pmI doubt it. Halting problem and all that.But that isn't a reason for choosing a language that avoids common problems.QuoteGood 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 theapplication'sproblem rather than thetools'problems.QuoteNaively counting such things rarely leads to enlightenment!

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 10:00:08 pm
content: Quote from: Nominal Animal on April 18, 2021, 09:42:57 pmAnd 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.QuoteFrom yesterday's comp.risks, againCosmic 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 +0900https://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.jpegThe 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#subj3However telecom systems are designed and implemented with thepresumptionthat errors will occur and bits of the network will disappear without warning.QuoteDefects in a "castle built on sand" do not excuse building on sand rather than on rock.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 18, 2021, 10:08:16 pm
content: 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.

author: bd139
author_rank: Super Contributor
timestamp: April 18, 2021, 10:24:31 pm
content: Quote from: Ed.Kloonk on April 18, 2021, 10:08:16 pmBetter that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 10:34:13 pm
content: Quote from: bd139 on April 18, 2021, 10:24:31 pmWhich is also a classic argument in favour of languages that support garbage collectorsDoubly so for languages where every developer creates their own reference counting garbage collector.

author: bd139
author_rank: Super Contributor
timestamp: April 18, 2021, 10:35:46 pm
content: It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.Applying that to C is fairly easy.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 10:42:12 pm
content: Quote from: bd139 on April 18, 2021, 10:35:46 pmNIH 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.

author: bd139
author_rank: Super Contributor
timestamp: April 18, 2021, 10:52:24 pm
content: Quote from: tggzzz on April 18, 2021, 10:42:12 pmI 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)

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2021, 11:03:33 pm
content: Quote from: bd139 on April 18, 2021, 10:52:24 pmOne 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.QuoteI'm ambivalent about Go and Rust, but they have a good starting point in that they've nicked concepts from CSPI 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.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 19, 2021, 01:14:31 am
content: Quote from: bd139 on April 18, 2021, 10:24:31 pmOnly 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 09:18:49 am
content: Quote from: Ed.Kloonk on April 19, 2021, 01:14:31 amAs 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.

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 10:28:52 am
content: Quote from: Ed.Kloonk on April 19, 2021, 01:14:31 amNope.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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 19, 2021, 04:07:35 pm
content: Quote from: tggzzz on April 18, 2021, 09:44:07 pmFully 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.Quote from: tggzzz on April 18, 2021, 09:44:07 pmAbsolutely! 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 usepiling(driving heavy stilts or posts into the swamp and sand to create a stableenoughbase 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.)

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 04:29:11 pm
content: Scheme makes a good systems programming languageAs 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 04:46:16 pm
content: Quote from: bd139 on April 19, 2021, 04:29:11 pmI thought you made your money clearing up the messes dropped buy other people!

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 04:58:53 pm
content: Quote from: Nominal Animal on April 19, 2021, 04:07:35 pmYes indeed. Hammers vs screwdrivers and all that. But you can insert screws with hammers.QuoteSmalltalk, xC, or macro assemblerMore reasonably, Ada, SPARK or - if they pan out - Rust or Go.QuoteA 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!

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 05:06:24 pm
content: Quote from: tggzzz on April 19, 2021, 04:46:16 pmYes by creating new piles of shit

author: DiTBho
author_rank: Super Contributor
timestamp: April 19, 2021, 05:11:53 pm
content: Quote from: westfw on April 18, 2021, 05:04:58 amlike DOS with TSR

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 06:37:42 pm
content: Quote from: DiTBho on April 19, 2021, 05:11:53 pmDOS 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 isyours!

author: DiTBho
author_rank: Super Contributor
timestamp: April 19, 2021, 07:04:19 pm
content: Quote from: tggzzz on April 19, 2021, 06:37:42 pmDOS 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 07:33:30 pm
content: I'm only too we'll aware of what MSDOS wasIt 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

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 07:43:13 pm
content: Quote from: DiTBho on April 19, 2021, 07:04:19 pmFORTH kernel. Collapse OS is interesting:https://collapseos.org/Plus you can build some hardware it'll run on!Also Brad Rodriguez's Moving FORTH series is interestinghttps://www.bradrodriguez.com/papers/moving1.htmFORTH is not a language or an OS or a toolchain. It's just completely different.

author: PlainName
author_rank: Super Contributor
timestamp: April 19, 2021, 07:55:27 pm
content: QuoteYes, 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.QuoteIndeed, 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.QuoteApparently notthatfamous. 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 issueper seand applied to, well, interfaces of that time. Maybe your memory of that (and of what DOS was/wasn't) could do with a refresh.---FromWikipedia:QuoteAlso fromWikipedia, linked to above, with my emphasis:Quote

author: DiTBho
author_rank: Super Contributor
timestamp: April 19, 2021, 07:59:23 pm
content: Quote from: tggzzz on April 19, 2021, 07:33:30 pmI spent 5 years on a DOS machine with Turbo Assembler, Turbo Pascal, Turbo Basic and Turbo CI learned a lot, then I moved to a UNIX "single user" (yes, incredible) machine: BeOS! Then to Linux.happy days ... 20? 30? years ago

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 08:12:14 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 08:16:07 pm
content: Quote from: bd139 on April 19, 2021, 07:43:13 pmYou can say that about Smalltalk or Squeak.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 08:25:57 pm
content: Quote from: bd139 on April 19, 2021, 08:12:14 pmAs 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.

author: bd139
author_rank: Super Contributor
timestamp: April 19, 2021, 08:40:00 pm
content: 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 ARXhttps://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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 08:54:46 pm
content: 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

author: DiTBho
author_rank: Super Contributor
timestamp: April 19, 2021, 09:50:33 pm
content: 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 runsclient'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_readThere 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 assemblyAnyway, this is not an OS, it's just a bootloader able to talk with a remote filesystem-core.

author: coppice
author_rank: Super Contributor
timestamp: April 19, 2021, 10:18:06 pm
content: Quote from: bd139 on April 19, 2021, 08:12:14 pmYes 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.

author: tggzzz
author_rank: Super Contributor
timestamp: April 19, 2021, 11:05:33 pm
content: It was sad that Windows was such a thin layer on top of MSDOS, continuing its limitations plus introducing extra complexity.

author: rfclown
author_rank: Frequent Contributor
timestamp: April 19, 2021, 11:26:22 pm
content: Quote from: coppice on April 19, 2021, 10:18:06 pmI'm running Windows 10.C:\2>echo a>aC:\2>copy a+a baa1 file(s) copied.C:\2>dirVolume in drive C has no label.Volume Serial Number is 148E-1AFCDirectory of C:\204/19/2021 07:18 PM <DIR> .04/19/2021 07:18 PM <DIR> ..04/19/2021 07:18 PM 3 a04/19/2021 07:18 PM 7 b2 File(s) 10 bytesSo 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.

author: rfclown
author_rank: Frequent Contributor
timestamp: April 20, 2021, 12:07:24 am
content: Quote from: dunkemhigh on April 19, 2021, 11:48:07 pmI 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.

author: Nusa
author_rank: Super Contributor
timestamp: April 20, 2021, 07:33:34 am
content: Quote from: rfclown on April 20, 2021, 12:07:24 amWindows 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.

author: westfw
author_rank: Super Contributor
timestamp: April 20, 2021, 07:42:14 am
content: QuoteWell, 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.QuoteMeh. 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."

author: bd139
author_rank: Super Contributor
timestamp: April 20, 2021, 08:20:53 am
content: 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.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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 20, 2021, 11:16:31 am
content: Quote from: rfclown on April 20, 2021, 12:07:24 amWhen 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 differentAt 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)(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 libraries9 floppy disks for these, paid 400 euro for this!

author: DiTBho
author_rank: Super Contributor
timestamp: April 20, 2021, 11:29:32 am
content: Quote from: westfw on April 20, 2021, 07:42:14 amI 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 CWhy 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"Oh, not bad, at least it helped make the skeleton the smallest possible

author: rstofer
author_rank: Super Contributor
timestamp: April 20, 2021, 02:11:13 pm
content: Quote from: westfw on April 20, 2021, 07:42:14 amDigital 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.

author: MIS42N
author_rank: Frequent Contributor
timestamp: April 24, 2021, 01:01:57 pm
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 24, 2021, 01:27:58 pm
content: Quote from: MIS42N on April 24, 2021, 01:01:57 pmWhich CPU are you using for this?

author: MIS42N
author_rank: Frequent Contributor
timestamp: April 24, 2021, 09:31:51 pm
content: Quote from: DiTBho on April 24, 2021, 01:27:58 pmPIC16F1455. 10MHz external clock, internal x4 PLL for internal clock, = 10MHz instruction time.

author: rfclown
author_rank: Frequent Contributor
timestamp: May 04, 2021, 12:21:52 am
content: Quote from: MIS42N on April 24, 2021, 01:01:57 pmCompletely 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 04, 2021, 07:26:02 am
content: Quote from: rfclown on May 04, 2021, 12:21:52 amThat 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.

author: newbrain
author_rank: Super Contributor
timestamp: May 04, 2021, 07:54:17 am
content: Quote from: brucehoult on May 04, 2021, 07:26:02 amI 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 instructionsThe data segment holds global variablesThe stack segment holds return addresses and local variablesThe 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 withNew()Of course, those were times when 64 kB per each segment was a respectable size...

author: brucehoult
author_rank: Super Contributor
timestamp: May 04, 2021, 09:12:15 am
content: Quote from: newbrain on May 04, 2021, 07:54:17 amRight.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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2021, 08:28:12 am
content: Quote from: brucehoult on May 04, 2021, 07:26:02 amThe 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-onwartsgoodies made me appreciate the risc-like simplicity of the 8080The 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.

author: bd139
author_rank: Super Contributor
timestamp: May 05, 2021, 08:56:27 am
content: Oh I'd forgotten about that. Thanks for the headache. Going to dream about FP_ macros and far pointers tonight nowI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 05, 2021, 10:15:45 am
content: Quote from: tggzzz on May 05, 2021, 08:28:12 am6502 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.Code:add16:clclda $00,Xadc $0000,Ysta $00,Xlda $01,Xadc $0001,Ysta $00,XrtsTwice (or more) as compact to call as to use inline code, and about 60% of the speed (more for 32 bit functions)Code:ldy #src ; might already be correct, so can often be omittedldx #dst ; might already be correct, so can often be omittedjsr add16Not quite as compact as SWEET16 or USCD P-system etc bytecode (but not far off), but ~5 times faster.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2021, 10:26:39 am
content: 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

author: bd139
author_rank: Super Contributor
timestamp: May 05, 2021, 10:35:38 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2021, 11:00:17 am
content: Quote from: bd139 on May 05, 2021, 10:35:38 amRoger 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)

author: bd139
author_rank: Super Contributor
timestamp: May 05, 2021, 11:57:44 am
content: 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 possibleI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 05, 2021, 12:12:16 pm
content: Quote from: bd139 on May 05, 2021, 10:35:38 amAhhh .. 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.QuoteNot 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.QuoteI 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.

author: MIS42N
author_rank: Frequent Contributor
timestamp: May 06, 2021, 02:37:16 pm
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: May 06, 2021, 03:03:36 pm
content: 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.