B# language for embedded development. And as a D competitor

[pragma]

In article <dvuvna$2314$1 at digitaldaemon.com>, kris says...
>
>Bee Sharp wrote:
>> Excelent article about a new language targeted to embedded development.
>> 
>> http://www.embedded.com/showArticle.jhtml?articleID=183700818
>> 
>> "The B# language includes efficient boxing/ unboxing conversions, field
>> properties, device addressing registers, interrupt handlers, deterministic
>> memory defragmenter, and multi-threading capabilities."
>
>That is interesting. The ioreg and interrupt handling is nicely done. D 
>could certainly learn a thing or two from the get|set accessor design ~ 
>very clean.
>
>That said, B# is not really targeted at the devices claimed ~ you really 
>need more than a couple KB of RAM for a class-oriented system. Thus it's 
>more likely to be targeting devices with a MB or more of memory; such as 
>phones and PDAs, etc. This is a huge market where I keep harping on 
>about D having a great opportunity to shine, and establish a solid 
>foothold. Just think about how many phones there are in the world 
>compared to PC's; and take a look at growth statisitics for India and 
>China (of cell providers). Hardly surprising B# is targeted right there.
>
>Anyway; if D had an equivalent mechanism for handling ioreg & 
>interrupts, and GDC were hooked up to the GCC ARM and H8S backends, B# 
>would not have much very offer in comparison (although the B# get|set 
>design is far more elegant IMO). I suppose one could use alias and/or 
>templates to provide an equivalent for ioreg? The embedded assembler 
>would be seriously useful (assuming it supported the target device)
>
>Thoughts?
>
>- Kris

Funny, this showed up on digg.com today too.  Anyway, I feel that a VM is still
a VM no matter how you build it; however the source-code compression
side-effects are kind of neat.  You're right: if not for the few features that
cater to embedded devices, not to mention that it's already targeted for them,
it wouldn't be much of a match for D.

The ioreg features look like something borrowed from an HLA or somesuch.  So
they're somewhere between a pointer, a constant and a property.  As it turns
out, it makes for an amazingly clean syntax for writing to a fixed address.


D Property (hard to maintain, relies on inlining)
-----------
ubyte portA(){ return *cast(ubyte*)(cast(void*)0x01234567); }
void portA(ubyte b){ *cast(ubyte*)(cast(void*)0x01234567) = b }

ubyte foo = portA; // read
portA = 0xFF; // write


C/D Pointers (harder to maintain, requires explicit pointer dereferencing)
------------
ubyte* portA = cast(ubyte*)(cast(void*)0x01234567); // no read/write protection

ubyte foo = *portA; // read
*portA = 0xFF; // write


D Register Template (hides some details, still relies on inlining)
-------------------
struct Register(T,uint addr){
T opCall(){ return *cast(T*)(cast(void*)addr); }
void opCall(T value){ *cast(T*)(cast(void*)addr) = b; }
}

Register!(ubyte,0x01234567) portA;

ubyte foo = portA; // read
portA = 0xFF; // write


B# register (short and sweet, dead-simple to optimize)
-------
ioreg8 portA = 0x01234567{ get; set; }

ubyte foo = portA; // read
portA = 0xFF; // write

- EricAnderton at yahoo