On Sat, 2013-12-21 at 11:29 -0800, Walter Bright wrote: > On 12/21/2013 6:44 AM, Russel Winder wrote: > > Inline assembly means you have to have the assembly code for each > > supported platform in the code with all the conditionals to the > > compiler. Having separate files is often much easier to manage and to > > build from. > > You can still put D inline assembly in separate files. What you don't need is > an > assembler.
But this implies the D compiler has to be able to handle Intel, Sparc, AMD, ARM, ARM Thumb, Atmel, … Certainly compiler code generators have to know things about the target, but does this necessarily include the ability to do inline? D compile-time decision making certainly changes the game compared to C/C++, but the problem is that D only really supports Intel just now so we don't really have data on how complicated things are for multiple backends. Of course having exited the embedded space (8051, Atmel, etc.) I am now just Intel/AMD/ARM oriented. > > OK so D only support Intel processors just now so only one inline > > assembly type, but this is part of the problem not the solution. > > There is no case where D's support for intel inline assembler is worse than > forcing you to use a separate assembler. My point is really that D needs to support ARM pdq to have any chance of getting traction in an increasingly bi-partisan (Intel/AMD and ARM) rather than monopolistic (Intel/AMD) data centre. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
