Fedora Linux Support Community & Resources Center

Go Back   FedoraForum.org > Community Lounge > Wibble
FedoraForum Search

Forgot Password? Join Us!

Wibble A place to have a sensible chat, about anything non linux related. Please remember that political and religious topics are not permitted.

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 2nd May 2012, 03:38 PM
mmix Offline
Registered User
 
Join Date: Aug 2009
Posts: 1,146
linuxfirefox
decac, A higher-level assembly language

https://code.google.com/p/decac/

Quote:
Deca is a language designed to provide the advanced features of sophisticated, high-level programming languages while still programming as close as possible to the bare metal. It brings in the functional, object-oriented, and generic programming paradigms without requiring a garbage collector or a threading system, so programmers really only pay in performance for the features they use.

Deca will provide:

UTF-8 strings
First-class functions, including lexical closures and lambdas
Pattern matching
A CLOS-style object system with multimethods and their overrides operating on variants
Exceptions and exception handling (really just a special case of variants with some LLVM intrinsics to pass them up the stack)
Scoped implicit parameters (for type-based dispatch as in type-classes)
Hierarchical modules
Binary compatibility for linking to libraries written in C
https://code.google.com/p/decac/source/browse/examples
Reply With Quote
  #2  
Old 2nd May 2012, 05:52 PM
Gareth Jones Offline
Official Gnome 3 Sales Rep. (and Adminstrator)
 
Join Date: Jul 2011
Location: Birmingham, UK
Age: 32
Posts: 2,771
linuxfirefox
Re: decac, A higher-level assembly language

I'm not sure it can be called "higher-level assembly", it looks more like "yet-another-C++" to me. Not that there's anything wrong with that of course, some people may prefer (yet-another-)syntax.
Reply With Quote
  #3  
Old 11th May 2012, 03:14 AM
birdwatcher
Guest
 
Posts: n/a
macossafari
Re: decac, A higher-level assembly language

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.
Reply With Quote
  #4  
Old 11th May 2012, 05:50 AM
aleph Offline
Banned (for/from) behaving just like everybody else!
 
Join Date: Jul 2007
Location: Nanjing, China
Posts: 1,332
linuxfirefox
Re: decac, A higher-level assembly language

Quote:
Originally Posted by Gareth Jones View Post
I'm not sure it can be called "higher-level assembly", it looks more like "yet-another-C++" to me. Not that there's anything wrong with that of course, some people may prefer (yet-another-)syntax.
It looks like yet-another-Lisp without the (()()((()((()())(()))))(there's a missing parenthesis somewhere)
__________________
Code:
from rlyeh import cthulhu
cthulhu.fhtagn()

Last edited by aleph; 11th May 2012 at 05:53 AM.
Reply With Quote
  #5  
Old 11th May 2012, 11:16 AM
stevea Online
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,999
linuxfirefox
Re: decac, A higher-level assembly language

Quote:
Originally Posted by birdwatcher View Post
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 View Post
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.
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe

Last edited by stevea; 11th May 2012 at 11:20 AM.
Reply With Quote
  #6  
Old 11th May 2012, 01:23 PM
aleph Offline
Banned (for/from) behaving just like everybody else!
 
Join Date: Jul 2007
Location: Nanjing, China
Posts: 1,332
linuxfirefox
Re: decac, A higher-level assembly language

Hi,

I have no peeve against the Lisp syntax (and decac neither). I meant to say decac's language model has (IMO) more similarities with Lisp than with C++. However the syntax does look more C-family-ish.
__________________
Code:
from rlyeh import cthulhu
cthulhu.fhtagn()
Reply With Quote
  #7  
Old 11th May 2012, 01:33 PM
stevea Online
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,999
linuxfirefox
Re: decac, A higher-level assembly language

Hi Aleph - I don't think he language is very lisp-like at all. The Thesis or whatever *claims* that functional programming was a driver for the design, but I really don't see it in the rest of the paper. Some vague refrence to lamda calc in the design, but not in the language features I think. To me it looks very OO with a few special tricks. I could be wrong.
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe
Reply With Quote
  #8  
Old 11th May 2012, 01:48 PM
birdwatcher
Guest
 
Posts: n/a
macoschrome
Re: decac, A higher-level assembly language

Quote:
Originally Posted by stevea View Post
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.
I guess this is what happens when I tell a joke that is too complex for people to spot. =/ Ofc I was playing ignorant.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] JB not detecting negative numbers (Assembly language 8086) Raman009 Programming & Packaging 1 11th May 2011 12:11 AM
Baremetal.img, so that i can learn 64 bit Assembly Language... El1iP3S01D Using Fedora 4 20th July 2010 06:00 AM
learning assembly language on fedora 10 User101 Programming & Packaging 5 7th August 2009 09:48 PM
Assembly language ? converting ascii to decmial matt123 Programming & Packaging 3 27th April 2009 08:10 AM
Any "higher Level" tools for module hacking olwe Programming & Packaging 2 23rd January 2006 11:00 PM


Current GMT-time: 08:38 (Saturday, 29-11-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat
Old Navy 4Th & Market Instagram Photos - Montemar Beach Club, Bataan Instagram Photos - Reggies Photos on Instagram - Adana-Mersin Otoban