DexOS wrote:As a example, i could teach anyone that really wants to learn to code, to code in ASM, just as fast as any other language, as long as they were wired right.
Different languages only exist because there is a (sometimes perceived) need for them. Turing-completeness means that all Turing-complete languages are ultimately equivalent, but that's largely a theoretical statement - different languages have different strengths <joking mode="or am I"> except for BASIC </joking>.
Assembler is useful (and, indeed, necessary) in certain cases. But in most cases, it's far easier to write (and understand, and, above all, maintain) code in a higher level language. So while it's usually necessary to write stuff like atomic operations and top level interrupt handlers in assembler, it's far easier to write (for example) the code that maintains a balanced binary tree of mutable strings ordered by some arbitrary hashing function in a higher level language.
"But compilers spit out suboptimal code", I hear you wailing. Yes, they do. Take, for example, the replacement memcpy and memset functions we were looking at last week. By using some relatively intimate knowledge of the hardware, and by throwing away any idea of portability (even across processors of the same family), we were able to improve by a massive factor (and the tiny factor I added towards the end) the performance of these low-level functions
on the Pi hardware as it stands. And that's where, outside of low level booting, assembler has its place for programmers who aren't writing compilers - in improving the performance of identified hotspots. I haven't picked apart any of the later stuff you've put out, but looking at the first release of DexOS for the Pi, it would be significantly faster if written in C. This doesn't mean you're a bad programmer, this means that in most cases, outoptimising even the most naive compiler is more work than it's worth, and results in code that's hard to follow and harder to maintain.
"I can get around the readability issue by implementing a macro-level language that spits out assembler", I hear you say. Yes, you can. The downside to this is that the code it generates out will be vastly less optimal than than anything a sane compiler would spit out, and you're usually restricted to producing something that's horrible to program with in high level terms as well. And it's fragile, and nonportable, and a thousand other little "gotchas" that aren't obvious in the first place.
Assembler is also vastly more buggy. Any given programmer will produce roughly the same number of bugs per KLoC regardless of language. There is a slight bias to less bugs as the level of abstraction is increased, but you might as well treat it as a flat line. Assembler, being a language, is part of this, and assembler requires more lines of code to carry out a given task than any language I can think of <joking mode="or am I"> outside of COBOL </joking>.
The unpleasant truth is that operating system projects written purely in assembler don't take off. The idea is appealing ("raw performance" etc) but the reality is suboptimal, unmaintainable and totally unportable code that doesn't do half of what an OS written in a higher level language and only using assembler where it makes real sense would do in a hundredth of the development time. I'm gonna pick on you here Craig, but please don't take it personally - you've spent ten years of your life producing DexOS, and it's a fairly impressive feat - I take my hat off to you for getting that far. But it's still a single-tasking, buggy, "toy" OS that's actually of no real use to anyone. Apart from what you've learned doing it, that's ten years effectively wasted (although it's your time, and it's probably no more wasted than the majority of the stuff I've produced over the last ten years) and you don't seem to have learned the most important lesson of all, which is "sane people don't implement operating systems in pure assembler".
Now, I would take your statement above as also being wrong. You can teach certain aspects of programming using assembler, but there are whole swathes of extremely useful stuff that, while they can be expressed in assembler, cannot be easily explained using it. Certainly not enough to introduce a concept and how it can be used to someone totally unfamiliar with it.
Simon
.
