Sean Kelly 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."
> 
> 
> Why not just call it C-flat?
> 
> 
> Sean

Well, B# is technically equivalent to the C note...

C-flat would therefore just be B.

-- 
Regards,
James Dunne

James Dunne wrote:
> Sean Kelly 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."
>>
>>
>> Why not just call it C-flat?
> 
> Well, B# is technically equivalent to the C note...
> 
> C-flat would therefore just be B.

Ah well, I tried :-p

In all seriousness, the language seems decent but I didn't see any features it offered over D.  It mostly seems like a very stipped down version of C#, and while it may or may not be ideal for embedded programming, I can't think of a reason I'd like to use it outside that arena.  I did also thing it was weird that they placed so much importance on boxing and unboxing that they maintain runtime type flags for *all* variables simply to make the process more efficient.  For a system that's short on memory, is such a per-variable overhead actually desirable?  And how does it affect struct layout?  Classes are nice, but B#, while lean on features, seems like it could be a bit bloated and slow on low-end embedded machines.


Sean

In article <dvv4r6$29ii$1@digitaldaemon.com>, MicroWizard says...
>Try implementing this language on PIC16Fxx or on 8051 etc... They are joking...

Well, the BX24 managed something similar (ish, albeit VB-like syntax) on Atmel. But heap space *is* at a premium on these things.

pragma wrote:
> MicroWizard says...
> 
>>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)!

(Ahhhhh, my Commodore VIC-20!! (Looking into the horizon, tear of affection and longing on cheek) Those were the times!)


Reading the D specs, the day we see D on any of the above processors, will simply never come.

I could kill for a D subset that worked on them.

In the worst case, I'd be happy with even a Tiny-C like thing with D syntax and no GC, for 8bit processors.

Think how nice it would be if we could use "the same syntax" on PIC and Athlon!