digitalmars.D - B# language for embedded development.
- Bee Sharp (5/5) Mar 23 2006 Excelent article about a new language targeted to embedded development.
- kris (20/27) Mar 23 2006 That is interesting. The ioreg and interrupt handling is nicely done. D
- Brad Roberts (9/40) Mar 23 2006 There's nothing stopping anyone from fleshing out the gdc support for ar...
- kris (8/52) Mar 23 2006 I wish! :-)
- pragma (35/62) Mar 23 2006 Funny, this showed up on digg.com today too. Anyway, I feel that a VM i...
- Sean Kelly (3/10) Mar 23 2006 Why not just call it C-flat?
- James Dunne (6/22) Mar 23 2006 Well, B# is technically equivalent to the C note...
- Sean Kelly (14/32) Mar 24 2006 Ah well, I tried :-p
- MicroWizard (12/17) Mar 23 2006 It stinks.
- pragma (3/12) Mar 23 2006 heh.. Much less a 6502 with 2k of RAM (nesdev.parodius.org)!
- Georg Wrede (10/16) Mar 24 2006 (Ahhhhh, my Commodore VIC-20!! (Looking into the horizon, tear of
- James Mansion (3/5) Mar 24 2006 Well, the BX24 managed something similar (ish, albeit VB-like syntax) on...
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
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
On Thu, 23 Mar 2006, kris wrote:Bee Sharp wrote: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, BradExcelent 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
Mar 23 2006
Brad Roberts wrote:On Thu, 23 Mar 2006, kris wrote: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).Bee Sharp wrote: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.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
Mar 23 2006
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
kris <foo bar.com> pragma wrote:In article <dvv16o$250d$1 digitaldaemon.com>, kris says...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?(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
In article <dvuvna$2314$1 digitaldaemon.com>, kris says...Bee Sharp wrote: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 yahooExcelent 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
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
Sean Kelly wrote:Bee Sharp wrote:C-flat would therefore just be B. -- Regards, James DunneExcelent 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
James Dunne wrote:Sean Kelly wrote: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. SeanBee Sharp wrote:C-flat would therefore just be B.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?
Mar 24 2006
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
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
pragma wrote:MicroWizard says...(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!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)!
Mar 24 2006
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