Quote:
Originally Posted by birdwatcher
Isnt the main sexyness of asm to keep it Old School and just trying to keep the code really small and stuff? Maybe not lol.  |
Could you be more wrong ? The special-sauce of asm is that you can exercise EVERY instruction for an architecture. No conventional compiler does that.
C is a nice compiler for OS procedures for example, but it can't generate ANY of the privileged instructions that manipulate the special CPU control registers or the MMU & Cache hardware. If you examine the kernel you'll find that all the lowest level MMU routines, the boot-up CPU config and some of the task switching relies on asm routines. It's not a huge amount of code and much is written as a set of per-architecture methods (a set for x86, another set for PPC another set for ARM, ...).
Also many compilers don't generate some of the 'special' instructions. For example gcc never generated the x86 SIMD instructions till v3.4 IIRC, and even then it requires special syntax. Many of the special x86 instructions require gcc builtin functions, same for PPC altivec, and many (hundreds) of ARM instructions. So at best we can say that gcc only generates these special instructions using unweildy hack-y built-in calls. So a lot of times you need to write libraries in asm for these special CPU features.
There is no language constructs (aside from a hack-y builtin call) that can represent an x86 AES crypto function instruction call - so the language is simply inadequate to represent this. Further I don't think it will ever be represented in any general purpose language.
Quote:
Originally Posted by aleph
It looks like yet-another-Lisp without the (()()((()((()())(()))))(there's a missing parenthesis somewhere)
|
If you mean the language syntax looks awful or lisp-like - I can't agree. This isn't so bad.
Code:
unsafe module construct
import malloc
function new<a>(object: a,destructor : a@−> Unit): @a {
let(result:= cast <@[a, destructor: a @−> Unit] > (malloc:: malloc
(sizeof([a, a@−> Unit])))){
result^.[0]:= a;
result^.destructor := destructor;
@result^.[0];
}
}
function delete <a>(object: @a): Unit {
let (tuple:= cast <@[a, destructor: a@−> Unit]>(object)) {
(tuple^.destructor)(tuple^.[0]);
malloc::free(cast<@byte>(tuple))
}
}
end
More important Lisp is a functional language - and Deca is not, despite the thesis nod to functional programming.
To me Deca
looks like a conventional OO language, not dissimilar to C++, but with a lot of changes to address system programming - light weight and replaceable run-time and some special features to deal with memory manipulation, (but w/o pointers !!!). My guess is that it's just an academic exercise, it wasn't released so much as it escaped academia. Nice thesis project but it's not going anywhere.
I could be wrong - but the proof of the pudding is in the execution; we have to see someone builds a serious toy OS in this language and then look at how it addresses the many complex issues of systems code.
======
FWIW someone a few years ago was hacking the Linux kernel to compile via the g++ compiler and has added some hacks to create real methods the the C-language ersatz methods for VFS. The play (not real work) stopped after an lkml discussion on why this wasn't even going to be accepted, and likely would never work. The main impediment is the C++ runtime, not the procedural code generated. You can't use constructors when you have no page-tables of stack setup. You can't use 'new' to allocate pages. Personally I *think* objective-C might be a reasonable compromise, and Deca seems to have gone in a bit different direction that includes some good workable ideas - but it's not ready for production use (based on other's comments).
---------- Post added at 05:16 AM ---------- Previous post was at 04:53 AM ----------
--- more
The problem is that no single language has all the features needed for OS writing.
When we are allocating resources (memory, CPU ,...(the stuff of cgroups)) we'd like a no-side-effects declarative functional language that is subject to mathematical proof.
When we are manipulating variant structures - like the VFS file systems interface, loadable drivers, fuse file-systems, the sets of security models and the several scheduling algorithms, and even the several structures for processes, kernel-threads and threads - then we would prefer an OO language with at least basic class inheritance features.
When we are writing heavily used code - like the clock processing that gets called a zillion times - we need to be able to very carefully direct the code generation so that there is minimal branching for the most common case - that speaks to a low level language like asm. In practice C works too but we'd prefer a clear language directive to manage this.
I could go on - but the point is the OS is a thorny piece of code with a lot of disparate requirements. No common language is well suited. Asm is far too low level, and C++ and other OOs bring too much overhead into play and sometimes can't express simple procedural code in a sufficiently detailed/efficient way. C is 'just right' in a Goldilocks sense. We can do 98% of the low level carefully crafted procedural stuff w/o lapsing into asm. We can create structures that act like OO methods & classes and dynamically manipulate these (but C is clunky at that).
Yes there can be a much better systems-programming language than C, and it should include both OO and functional-programming concepts. I'm not convinced that Deca is more than a good stab in the right general direction.
Linear Mode
