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."

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

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."

Why not just call it C-flat?


Sean

On Thu, 23 Mar 2006, kris wrote:

> 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

There's nothing stopping anyone from fleshing out the gdc support for arm or any other processor.  It's a matter of someone taking the initiative. The best path to success would be for someone with the desire to use that system to step up and help get it working.  I'm sure whoever that person is would get sufficient support to make it work.

Wanna volunteer?  I don't have the hardware or usecase to do it myself.

Later,
Brad

Brad Roberts wrote:
> On Thu, 23 Mar 2006, kris wrote:
> 
> 
>>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
> 
> 
> There's nothing stopping anyone from fleshing out the gdc support for arm or any other processor.  It's a matter of someone taking the initiative.  The best path to success would be for someone with the desire to use that system to step up and help get it working.  I'm sure whoever that person is would get sufficient support to make it work.
> 
> Wanna volunteer?  I don't have the hardware or usecase to do it myself.


I wish! :-)

This needs someone with (a) some time (b) some expertise with GCC and linux. The first one is like gold for me, which explains the second to some degree. However, I'd hope that there's someone here who has both. David Freidman doesn't think it would be a big deal to get it done, and the backend for PocketPC/ARM has been built before (for GCC 3.3, I recall).

BTW: What do you think about the B# get|set design?

In article <dvuvna$2314$1@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

In article <dvv16o$250d$1@digitaldaemon.com>, kris says...
>
>
>BTW: What do you think about the B# get|set design?

(I know this wasn't exactly an open question, but...)

I think it's a bit like the 'readonly' proposal, warmed over.  Its basically the same thing as adding some attributes to get the job done in D:

readonly ubyte foo; // read-only
writable readonly ubyte foo; // default
writable ubyte foo; // write-only (mostly useless unless we have a 'register'
construct similar to B#)

IMO, the {get; set; } syntax just doesn't seem to jive with D to me.

- EricAnderton at yahoo

pragma wrote:
> In article <dvv16o$250d$1@digitaldaemon.com>, kris says...
> 
>>
>>BTW: What do you think about the B# get|set design?
> 
> 
> (I know this wasn't exactly an open question, but...)
> 
> I think it's a bit like the 'readonly' proposal, warmed over.  Its basically the
> same thing as adding some attributes to get the job done in D:
> 
> readonly ubyte foo; // read-only
> writable readonly ubyte foo; // default
> writable ubyte foo; // write-only (mostly useless unless we have a 'register'
> construct similar to B#)
> 
> IMO, the {get; set; } syntax just doesn't seem to jive with D to me.
> 
> - EricAnderton at yahoo


Except that it appears to map onto an overiddable method, with an implicit 'value' property for the set() ?

I could be mistaken, but B# get|set seems to be akin to an extensible property for class members? Kind of like an optional opEqual & opAssign for each D class/struct attribute?

It stinks.
In many ways.

- Windows CE ads everywhere on the page B-)
- Virtual machine ... Embedded system developers rarely think of any kind of
overhead...
- Java like (classes everywhere, no single functions)
- No mention to bit types/operations

Try implementing this language on PIC16Fxx or on 8051 etc... They are joking...

Best regards,
Tamas Nagy

In article <dvum5p$1mrs$1@digitaldaemon.com>, Bee Sharp says...
>
>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."
>
>

In article <dvv4r6$29ii$1@digitaldaemon.com>, MicroWizard says...
>
>It stinks.
>In many ways.
>
>- Windows CE ads everywhere on the page B-)
>- Virtual machine ... Embedded system developers rarely think of any kind of
>overhead...
>- Java like (classes everywhere, no single functions)
>- No mention to bit types/operations
>
>Try implementing this language on PIC16Fxx or on 8051 etc... They are joking...

heh.. Much less a 6502 with 2k of RAM (nesdev.parodius.org)!

- EricAnderton at yahoo