www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - B# language for embedded development.

reply Bee Sharp <Bee_member pathlink.com> writes:
Excelent article about a new language targeted to embedded development.

http://www.embedded.com/showArticle.jhtml?articleID=183700818


properties, device addressing registers, interrupt handlers, deterministic
memory defragmenter, and multi-threading capabilities."
Mar 23 2006
next sibling parent reply kris <foo bar.com> writes:
Bee Sharp wrote:
 Excelent article about a new language targeted to embedded development.
 
 http://www.embedded.com/showArticle.jhtml?articleID=183700818
 

 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. 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 Anyway; if D had an equivalent mechanism for handling ioreg & 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
Mar 23 2006
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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
 

 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. 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 Anyway; if D had an equivalent mechanism for handling ioreg & interrupts, and 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
Mar 23 2006
parent reply kris <foo bar.com> writes:
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


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. 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 Anyway; if D had an equivalent mechanism for handling ioreg & interrupts, and 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).
Mar 23 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <dvv16o$250d$1 digitaldaemon.com>, kris says...

(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' IMO, the {get; set; } syntax just doesn't seem to jive with D to me. - EricAnderton at yahoo
Mar 23 2006
parent kris <foo bar.com> writes:
pragma wrote:
 In article <dvv16o$250d$1 digitaldaemon.com>, kris says...
 

(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' 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() ? property for class members? Kind of like an optional opEqual & opAssign for each D class/struct attribute?
Mar 23 2006
prev sibling parent pragma <pragma_member pathlink.com> writes:
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
 

 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. 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 Anyway; if D had an equivalent mechanism for handling ioreg & 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 ------- ioreg8 portA = 0x01234567{ get; set; } ubyte foo = portA; // read portA = 0xFF; // write - EricAnderton at yahoo
Mar 23 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Bee Sharp wrote:
 Excelent article about a new language targeted to embedded development.
 
 http://www.embedded.com/showArticle.jhtml?articleID=183700818
 

 properties, device addressing registers, interrupt handlers, deterministic
 memory defragmenter, and multi-threading capabilities."
Why not just call it C-flat? Sean
Mar 23 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Sean Kelly wrote:
 Bee Sharp wrote:
 
 Excelent article about a new language targeted to embedded development.

 http://www.embedded.com/showArticle.jhtml?articleID=183700818


 properties, device addressing registers, interrupt handlers, 
 deterministic
 memory defragmenter, and multi-threading capabilities."
Why not just call it C-flat? Sean
C-flat would therefore just be B. -- Regards, James Dunne
Mar 23 2006
parent Sean Kelly <sean f4.ca> writes:
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


 properties, device addressing registers, interrupt handlers, 
 deterministic
 memory defragmenter, and multi-threading capabilities."
Why not just call it C-flat?
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 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 slow on low-end embedded machines. Sean
Mar 24 2006
prev sibling parent reply MicroWizard <MicroWizard_member pathlink.com> writes:
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


properties, device addressing registers, interrupt handlers, deterministic
memory defragmenter, and multi-threading capabilities."
Mar 23 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Mar 23 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
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!
Mar 24 2006
prev sibling parent James Mansion <James_member pathlink.com> writes:
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.
Mar 24 2006