www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Go compiler moving from C to Go

reply Ziad Hatahet <hatahet gmail.com> writes:
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1
Dec 18 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 19 December 2013 at 07:26:58 UTC, Ziad Hatahet wrote:

 https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1


I find it very positive. I follow Wirth's school of thought that
bootstraping is always the best option, after you get a minimal
language compiling.

Actually how is the effort of porting dmd to D going, any idea
when we could start playing with it?

--
Paulo
Dec 19 2013
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message

 Actually how is the effort of porting dmd to D going, any idea
 when we could start playing with it?


It's going quite well.  The D version passes the full test suite on win32, 
and can compile itself on linux64, as of this week.

There are some instructions here if you're up for building it yourself: 
https://github.com/D-Programming-Language/dmd/pull/1980

I think we're about two releases away (in terms of remaining work) from 
being able to ship ddmd on all supported platforms, and one more from 
switching over to D completely.

Unfortunately, it may take much longer (or never happen), because I am STILL 
waiting for Walter to move on 
https://github.com/D-Programming-Language/dmd/pull/2754
Dec 19 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/13 12:56 AM, Daniel Murphy wrote:

 https://github.com/D-Programming-Language/dmd/pull/2754


I will intervene there. All, prepare for destruction.

Andrei
Dec 19 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:l8udt4$1rqf$1 digitalmars.com...

 On 12/19/13 12:56 AM, Daniel Murphy wrote:

 https://github.com/D-Programming-Language/dmd/pull/2754


 I will intervene there. All, prepare for destruction.

 Andrei


That would be great.  I would very much like to start on the refactoring 
needed, and C+ mangling of templated structs is the only enhancement left in 
my patch list.
Dec 19 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 19 December 2013 at 08:56:45 UTC, Daniel Murphy
wrote:

 "Paulo Pinto" <pjmlp progtools.org> wrote in message

 Actually how is the effort of porting dmd to D going, any idea
 when we could start playing with it?


 It's going quite well.  The D version passes the full test 
 suite on win32,
 and can compile itself on linux64, as of this week.

 There are some instructions here if you're up for building it 
 yourself:
 https://github.com/D-Programming-Language/dmd/pull/1980

 I think we're about two releases away (in terms of remaining 
 work) from
 being able to ship ddmd on all supported platforms, and one 
 more from
 switching over to D completely.

 Unfortunately, it may take much longer (or never happen), 
 because I am STILL
 waiting for Walter to move on
 https://github.com/D-Programming-Language/dmd/pull/2754



Thanks for the update. Great work.

I might have some time to play with it during vacations.

--
Paulo
Dec 19 2013
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 19 December 2013 at 08:56:45 UTC, Daniel Murphy 
wrote:

 I think we're about two releases away (in terms of remaining 
 work) from
 being able to ship ddmd on all supported platforms, and one 
 more from
 switching over to D completely.


That's really cool! D is IMO a better fit for that kind of 
software than both C and Go (in terms of structure). I'd say it 
will be much more tempting to dabbel with it if it is in D. I'd 
even say it will be difficult not to! :)
Dec 19 2013
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Thursday, 19 December 2013 at 11:42:34 UTC, Ola Fosheim 
Grøstad wrote:

 I'd say it will be much more tempting to dabbel with it if it 
 is in D. I'd even say it will be difficult not to! :)


Couldn't agree more: I've been reading some sources of Phobos.
When compared to C++ standard library, it's a pleasure to read.
I wouldn't be bothering reading Phobos if it was such a mess.

Of course ddmd will be pretty much translated C++, but I guess 
lots of refactoring will be following shortly (for the 
compiler-as-library project).
Dec 19 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Francesco Cattoglio" <francesco.cattoglio gmail.com> wrote in message 
news:msurcjlmbxmbxpmrgtyy forum.dlang.org...

 On Thursday, 19 December 2013 at 11:42:34 UTC, Ola Fosheim Grøstad wrote:

 I'd say it will be much more tempting to dabbel with it if it is in D. 
 I'd even say it will be difficult not to! :)


 Couldn't agree more: I've been reading some sources of Phobos.
 When compared to C++ standard library, it's a pleasure to read.
 I wouldn't be bothering reading Phobos if it was such a mess.

 Of course ddmd will be pretty much translated C++, but I guess lots of 
 refactoring will be following shortly (for the compiler-as-library 
 project).


Lots and lots and lots and lots.
Dec 19 2013
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy 
wrote:

 Lots and lots and lots and lots.


I wish I could help, but I really know _nothing_ about compilers.
Dec 19 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-19 15:33, Francesco Cattoglio wrote:

 On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:

 Lots and lots and lots and lots.


 I wish I could help, but I really know _nothing_ about compilers.


That hasn't stopped me, for the small contributions I've made :)

-- 
/Jacob Carlborg
Dec 19 2013
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 19.12.2013 15:33, schrieb Francesco Cattoglio:

 On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:

 Lots and lots and lots and lots.


 I wish I could help, but I really know _nothing_ about compilers.


If you feel like learning about them, Compiler Construction from Niklaus 
Wirth is a very nice introduction.

http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf

I can provide other references on request.

--
Paulo
Dec 19 2013
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Thursday, 19 December 2013 at 15:48:07 UTC, Paulo Pinto wrote:

 Am 19.12.2013 15:33, schrieb Francesco Cattoglio:

 On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy 
 wrote:

 Lots and lots and lots and lots.


 I wish I could help, but I really know _nothing_ about 
 compilers.


 If you feel like learning about them, Compiler Construction 
 from Niklaus Wirth is a very nice introduction.

 http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf

 I can provide other references on request.

 --
 Paulo


I don't know, I feel like I would be more useful if I only 
sticked with working on the standard library when needed and 
writing software that others might find interesting (I'm planning 
on "resurrecting" SciD btw)
Dec 19 2013
next sibling parent "ed" <sillymongrel gmail.com> writes:
On Friday, 20 December 2013 at 01:40:37 UTC, Francesco Cattoglio 
wrote:

[snip]

 (I'm planning on "resurrecting" SciD btw)


[snip]

I've been using SciD for about 12 months and it does a fine job. 
It would be great to see it grow even more.

Cheers,
Ed
Dec 19 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 20/12/13 02:40, Francesco Cattoglio wrote:

 I don't know, I feel like I would be more useful if I only sticked with working
 on the standard library when needed and writing software that others might find
 interesting (I'm planning on "resurrecting" SciD btw)


Nice to know -- anything in particular you are keen to work on there?
Dec 22 2013
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Sunday, 22 December 2013 at 19:49:21 UTC, Joseph Rushton 
Wakeling wrote:

 On 20/12/13 02:40, Francesco Cattoglio wrote:

 I don't know, I feel like I would be more useful if I only 
 sticked with working
 on the standard library when needed and writing software that 
 others might find
 interesting (I'm planning on "resurrecting" SciD btw)


 Nice to know -- anything in particular you are keen to work on 
 there?


No real battleplan other than turning it into a DUB package, then 
I guess I will move from there. But first, I need to analyze and 
understand the 2 codebases: the Kyllingstad one and the cristicbz 
fork. I'd like to understand if there's any way to reconciliate 
them and/or which one is the "best" to start working on.
After that I'll probably look into linear algebra. But this will 
start next year. I need to properly learn D with this project (I 
only played with it untill now, no serious projects on the 
record).

Help is welcome, ofc. Kyllingstad himself wanted SciD to be a 
community effort.
Dec 23 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 23/12/13 12:57, Francesco Cattoglio wrote:

 No real battleplan other than turning it into a DUB package, then I guess I
will
 move from there. But first, I need to analyze and understand the 2 codebases:
 the Kyllingstad one and the cristicbz fork. I'd like to understand if there's
 any way to reconciliate them and/or which one is the "best" to start working
on.


Sounds good to me.  By the way, I think Cristi was considering targeting the 
linear algebra work towards Phobos -- you might like to consider if some parts 
of SciD could be reworked as standard library features, although obviously you 
have greater freedom to extend and experiment in an independent library.


 After that I'll probably look into linear algebra. But this will start next
 year. I need to properly learn D with this project (I only played with it
untill
 now, no serious projects on the record).


You are going to have a lot of fun.  Getting one's teeth seriously into D is a 
very pleasurable experience.

(Ways to know the internet has jaded you no. 43995123: understanding how 4chan 
users will read the previous sentence....:-)


 Help is welcome, ofc. Kyllingstad himself wanted SciD to be a community effort.


I'm interested, but it's always about time commitments.  But if you can come up 
with a TODO list, I'll promise to take a look :-)
Dec 23 2013
parent reply "CJS" <Prometheus85 hotmail.com> writes:
 Sounds good to me.  By the way, I think Cristi was considering 
 targeting the linear algebra work towards Phobos -- you might 
 like to consider if some parts of SciD could be reworked as 
 standard library features, although obviously you have greater 
 freedom to extend and experiment in an independent library.


I don't think anything related to linear algebra belongs in the 
standard library. See here, for example: 
http://forum.dlang.org/thread/rmyaglfeimzuggoluxvd forum.dlang.org?page=2#post-rfnnzssennvpxcihmcm
:40forum.dlang.org. 
The basic point is that linear algebra libraries are too 
dependent on hardware, available libraries, and implementation 
details to have any place in a language specific standard library.

But I definitely support a D matrix library getting some love and 
attention. Especially since, if I understood the SciD code 
correctly when I looked at it a month ago, it currently is a nice 
wrapper for a matrix type and solving matrix equations and 
finding eigenvalues. It lacks support for matrix multiplication, 
addition, etc.. I'm not sure if D's operator overloading is 
sufficiently rich to allow separate operators for matrix 
multiplication and element-wise multiplication in matrix. 
(Dealing with this is a pain in numpy, the most common Python 
matrix library, as well as in Eigen, a common c++ matrix library.)

Also worth noting Some of the most popular C++ matrix & linear 
algebra libraries, such as Eigen and Armadillo, are based on 
expression templates. This leads to not terribly readable code, 
which I suspect D could clean up. But that isn't anywhere near 
the first feature to add to a matrix library.
Dec 27 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/12/13 06:53, CJS wrote:

 I don't think anything related to linear algebra belongs in the standard
 library. See here, for example:
 http://forum.dlang.org/thread/rmyaglfeimzuggoluxvd forum.dlang.org?page=2#post-rfnnzssennvpxcihmcmb:40forum.dlang.org.
 The basic point is that linear algebra libraries are too dependent on hardware,
 available libraries, and implementation details to have any place in a language
 specific standard library.


Thanks for your detailed writeup and reference list there -- it's very useful.

My own take on this is pretty much: let's make sure that there is a nice
library 
which is Phobos-compatible -- by which I mean, its licence and coding style 
match what's in the standard library -- and approach any decisions about where 
it belongs on the basis of what gets created.

I imagine that putting in the effort to write a really good linear algebra 
library from scratch in D, with attention to all prior work, would probably be 
very rewarding and an excellent stress test of the language, but would also 
involve far too much effort given that we can bind what already exists.


 But I definitely support a D matrix library getting some love and attention.
 Especially since, if I understood the SciD code correctly when I looked at it a
 month ago, it currently is a nice wrapper for a matrix type and solving matrix
 equations and finding eigenvalues. It lacks support for matrix multiplication,
 addition, etc.. I'm not sure if D's operator overloading is sufficiently rich
to
 allow separate operators for matrix multiplication and element-wise
 multiplication in matrix. (Dealing with this is a pain in numpy, the most
common
 Python matrix library, as well as in Eigen, a common c++ matrix library.)


I don't see why in principle it shouldn't be doable.  Whether it's possible to 
directly define custom operators for this akin to what MATLAB/Octave have: .+, 
.-, .*, ./, etc. I'm not sure, but it ought to be possible to define some kind 
of DSL/template along the lines of:

     c = ElementWise!("a + b");
Dec 28 2013
parent reply "CJS" <Prometheus85 hotmail.com> writes:
 I'm not sure if D's operator overloading is
 sufficiently rich to
 allow separate operators for matrix multiplication and 
 element-wise
 multiplication in matrix. (Dealing with this is a pain in 
 numpy, the most common
 Python matrix library, as well as in Eigen, a common c++ 
 matrix library.)


 I don't see why in principle it shouldn't be doable.  Whether 
 it's possible to directly define custom operators for this akin 
 to what MATLAB/Octave have: .+, .-, .*, ./, etc. I'm not sure, 
 but it ought to be possible to define some kind of DSL/template 
 along the lines of:

     c = ElementWise!("a + b");


A variation of that is what numpy and Eigen use. In numpy, for
the array class '*' is element-wise by default and the function
np.dot is matrix multiplication. For Eigen '*' is matrix
multiplication by default while the (member) function
cwiseProduct is element-wise. One the one hand, this is more
readable than matlab or R in terms of having a clear default.
(Whereas in matlab you have to be careful to distinguish between
'.*' and '*', or '*' and '%*%' in R.) But it's both hideous to
look at and to type. An improvement over .add or .times in Java
matrix libraries, but far from Nirvana. I'm hoping D can do
better.
Dec 29 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 29 December 2013 at 21:26:33 UTC, CJS wrote:

 A variation of that is what numpy and Eigen use. In numpy, for
 the array class '*' is element-wise by default and the function
 np.dot is matrix multiplication. For Eigen '*' is matrix
 multiplication by default while the (member) function
 cwiseProduct is element-wise. One the one hand, this is more
 readable than matlab or R in terms of having a clear default.
 (Whereas in matlab you have to be careful to distinguish between
 '.*' and '*', or '*' and '%*%' in R.) But it's both hideous to
 look at and to type. An improvement over .add or .times in Java
 matrix libraries, but far from Nirvana. I'm hoping D can do
 better.


How would you like the syntax to be, in an ideal world?
Dec 30 2013
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Francesco Cattoglio" <francesco.cattoglio gmail.com> wrote in message 
news:xahqixgqvbnyimyhzabb forum.dlang.org...

 On Thursday, 19 December 2013 at 12:10:28 UTC, Daniel Murphy wrote:

 Lots and lots and lots and lots.


 I wish I could help, but I really know _nothing_ about compilers.


Well, that's where I was a few years ago.  Learning compilers by 
single-stepping through dmd probably isn't the easiest way, I'd recommend 
having a read of a compilers textbook or subject if you're interested.
Dec 19 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 I find it very positive. I follow Wirth's school of thought that
 bootstraping is always the best option, after you get a minimal
 language compiling.


Moving their Go compiler from C to Go seems a good idea, for the 
reasons they have listed. But moving all their other tools from C 
to Go seems a little too much.

Bye,
bearophile
Dec 19 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-12-19 at 12:23 +0100, bearophile wrote:
[…]

 Moving their Go compiler from C to Go seems a good idea, for the 
 reasons they have listed. But moving all their other tools from C 
 to Go seems a little too much.


I think not. The whole point of Go is to replace C, so it is right to
replace all use of C with Go for the Go toolchain.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 19 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 19 December 2013 at 11:31:10 UTC, Russel Winder
wrote:

 On Thu, 2013-12-19 at 12:23 +0100, bearophile wrote:
 […]

 Moving their Go compiler from C to Go seems a good idea, for 
 the reasons they have listed. But moving all their other tools 
 from C to Go seems a little too much.


 I think not. The whole point of Go is to replace C, so it is 
 right to
 replace all use of C with Go for the Go toolchain.


Fully agree. Only when the public at large starts to see GC
enabled languages used in contexts where C is known for, are they
convinced that C can be replaced.

What I advocate since I got in touch with Oberon.

Having the full toolchain done in Go already takes out of the
equation the typical "my compiler compiles yours" statement.


--
Paulo
Dec 19 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Russel Winder:


 The whole point of Go is to replace C,


I didn't know this.

Bye,
bearophile
Dec 19 2013
parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:

 Russel Winder:


 The whole point of Go is to replace C,


 I didn't know this.

 Bye,
 bearophile


Because it's no longer true at all. It was the goal at the 
beginning, but it's no longer, they've said that Go is not a 
system programming language (in the sense that you can construct 
an OS with it).
Dec 19 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:

 On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:

 Russel Winder:


 The whole point of Go is to replace C,


 I didn't know this.

 Bye,
 bearophile


 Because it's no longer true at all. It was the goal at the 
 beginning, but it's no longer, they've said that Go is not a 
 system programming language (in the sense that you can 
 construct an OS with it).


Even though I rather use D than Go, every time I read that, I am 
tempted to prove people wrong. If I had the time for it, that is.

Go offers the same mechanisms for systems programming as Oberon 
does. If ETHZ was able to create Native Oberon, AOS and EthOS 
with Oberon, why cannot one do an OS with Go?

--
Paulo
Dec 19 2013
next sibling parent reply "Araq" <rumpf_a web.de> writes:
On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:

 On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:

 On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile 
 wrote:

 Russel Winder:


 The whole point of Go is to replace C,


 I didn't know this.

 Bye,
 bearophile


 Because it's no longer true at all. It was the goal at the 
 beginning, but it's no longer, they've said that Go is not a 
 system programming language (in the sense that you can 
 construct an OS with it).


 Even though I rather use D than Go, every time I read that, I 
 am tempted to prove people wrong. If I had the time for it, 
 that is.

 Go offers the same mechanisms for systems programming as Oberon 
 does. If ETHZ was able to create Native Oberon, AOS and EthOS 
 with Oberon, why cannot one do an OS with Go?


Well I can't see a GC work well in a heavily concurrent kernel. 
BTW the latest incarnation of Oberon includes non-GC'ed pointers. 
But hey, what do I know...
Dec 20 2013
parent reply "pjmlp" <pjmlp progtools.org> writes:
On Friday, 20 December 2013 at 10:26:09 UTC, Araq wrote:

 On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:

 On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:

 On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile 
 wrote:

 Russel Winder:


 The whole point of Go is to replace C,


 I didn't know this.

 Bye,
 bearophile


 Because it's no longer true at all. It was the goal at the 
 beginning, but it's no longer, they've said that Go is not a 
 system programming language (in the sense that you can 
 construct an OS with it).


 Even though I rather use D than Go, every time I read that, I 
 am tempted to prove people wrong. If I had the time for it, 
 that is.

 Go offers the same mechanisms for systems programming as 
 Oberon does. If ETHZ was able to create Native Oberon, AOS and 
 EthOS with Oberon, why cannot one do an OS with Go?


 Well I can't see a GC work well in a heavily concurrent kernel.


Well AOS is concurrent, maybe not heavy concurrent but it does 
support parallel tasks.


 BTW the latest incarnation of Oberon includes non-GC'ed 
 pointers. But hey, what do I know...


Go also has them in the unsafe package. You can convert a pointer 
to an uintptr via the unsafe package. That is how you convert 
pointers between Go and C world, for example.

I think the whole discussion about GC based OS is like 
JavaScript. No one in the mainstream considered scripting 
languages fast, until Google released V8. Although Self 
implementation was already quite fast and used for Hotspot.

Now we have Julia already achieving C like speeds in some areas, 
although the implementation is still quite young.

So until a big company does something into this direction, people 
will keep ignoring what has been achieved so far in the academia.

--
Paulo
Dec 20 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
pjmlp:


 Now we have Julia already achieving C like speeds in some 
 areas, although the implementation is still quite young.


Julia compiles using LLVM, that is mature. But I think Julia uses 
light optimization parameters (I don't know if the optimization 
level can be changed).



 So until a big company does something into this direction, 
 people will keep ignoring what has been achieved so far in the 
 academia.


Lot of programmers ignore what academia does, this is a big 
problem.

Bye,
bearophile
Dec 20 2013
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 Lot of programmers ignore what academia does, this is a big 
 problem.


Because these programmers are not to be convinced by some arcane 
academic argument but by success stories of 'industrial' 
projects. I don't think that's too bad, somehow the bad academic 
ideas need to be filtered.

But now you have a chicken-egg problem and a academic world that 
has no reason to push it's work into industry. How to change this?
Dec 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-20 16:12, bearophile wrote:


 Lot of programmers ignore what academia does, this is a big problem.


Unfortunately the opposite is true as well. I read some article that 
here in Sweden the universities and other schools examines around 1000 
people in the area of game development. At the same time the industry 
only needs around 300 new people.

-- 
/Jacob Carlborg
Dec 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-20 08:03, Paulo Pinto wrote:


 Even though I rather use D than Go, every time I read that, I am tempted
 to prove people wrong. If I had the time for it, that is.

 Go offers the same mechanisms for systems programming as Oberon does. If
 ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
 cannot one do an OS with Go?


When developing an OS, for somethings these languages are not enough, 
including C, Go and D. You need to use assembly. D has the advantage of 
supporting inline assembly.

-- 
/Jacob Carlborg
Dec 20 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 20.12.2013 22:05, Jacob Carlborg wrote:

 On 2013-12-20 08:03, Paulo Pinto wrote:


 Even though I rather use D than Go, every time I read that, I am tempted
 to prove people wrong. If I had the time for it, that is.

 Go offers the same mechanisms for systems programming as Oberon does. If
 ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
 cannot one do an OS with Go?


 When developing an OS, for somethings these languages are not enough,
 including C, Go and D. You need to use assembly. D has the advantage of
 supporting inline assembly.


Until all D compilers provide the same support for inline assembly, it 
is better we don't use that as language feature.

Currently I rather write assembly with an external assembler than using 
a separate syntax per D compiler.

However you do touch a nice point, even ANSI/ISO C needs to rely on 
external assemblers to be useful at systems level. This is something 
developers forget when they equate language == what my compiler supports.

--
Paulo
Dec 20 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-21 07:26, Paulo Pinto wrote:


 However you do touch a nice point, even ANSI/ISO C needs to rely on
 external assemblers to be useful at systems level. This is something
 developers forget when they equate language == what my compiler supports.


You will most likely not be able to rely only on standard ANSI/ISO C. Be 
it either languages extension, using some pragma/attribute or some 
special flag. Things like force inline, placing data structures in 
special sections and so on.

-- 
/Jacob Carlborg
Dec 21 2013
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 21 December 2013 06:26, Paulo Pinto <pjmlp progtools.org> wrote:

 On 20.12.2013 22:05, Jacob Carlborg wrote:

 On 2013-12-20 08:03, Paulo Pinto wrote:


 Even though I rather use D than Go, every time I read that, I am tempted
 to prove people wrong. If I had the time for it, that is.

 Go offers the same mechanisms for systems programming as Oberon does. If
 ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
 cannot one do an OS with Go?



 When developing an OS, for somethings these languages are not enough,
 including C, Go and D. You need to use assembly. D has the advantage of
 supporting inline assembly.




While useful the ability to write inline assembler functions, DMD
can't inline these around the place. So you get all the benefits of
being able to shortcut the fastest route to do X, but with the
slowdown of 25% because there's a big elephant in the room.



 Until all D compilers provide the same support for inline assembly, it is
 better we don't use that as language feature.


That same support is never going to happen.  Not because of
disagreement, but because our backends are designed to work most
naturally in conflicting ways.  The same can be said for other (very)
low-level details, such as va_list type and va_arg functions,
low-level x86 intrinsics (inp, outp, y2lx...), and that
core.simd.__simd thingy.

x86-specific and x86-centric are implied on all DMD's features mentioned above.

Iain.
Dec 22 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Iain Buclaw:


 That same support is never going to happen.  Not because of
 disagreement, but because our backends are designed to work most
 naturally in conflicting ways.


I think this means that working to make DMD better is a good 
idea, because every compiler has different strengths, like Walter 
says.



 and that core.simd.__simd thingy.


What are the problems with that thing?



 x86-specific and x86-centric are implied on all DMD's features 
 mentioned above.


While the work to support other CPUs (and GPUs) is important, 
even at Phobos/language level, x86 is still an important CPU, so 
the work to make its support good is not wasted time :-)

Bye,
bearophile
Dec 22 2013
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Dec 23, 2013 12:00 AM, "bearophile" <bearophileHUGS lycos.com> wrote:

 Iain Buclaw:



 That same support is never going to happen.  Not because of
 disagreement, but because our backends are designed to work most
 naturally in conflicting ways.



 I think this means that working to make DMD better is a good idea,


because every compiler has different strengths, like Walter says.


For inline assembly, making dmd work better how?

The problem with inline assembly is much more fundamental. DMD emits object
code, so it makes sense to have a full blown assembler built into it.  In
contrast, GDC emits assembly, and AT&T syntax at that, so having anything
other than GCC-style inline assembly support is just plain awkward.


 and that core.simd.__simd thingy.



 What are the problems with that thing?


Not possible without some sort of translation map, which would be target
specific, so not suitable for GDC, and language specific so not suitable
for GCC either.

Also, falls under category of x86-centric below.


 x86-specific and x86-centric are implied on all DMD's features mentioned




above.

 While the work to support other CPUs (and GPUs) is important, even at


Phobos/language level, x86 is still an important CPU, so the work to make
its support good is not wasted time :-)


Indeed, but just keep that support out of the language spec, as it only
serves to hurt progress, and leads to extreme conflicts in design (I don't
tend to show it, but I do take extreme pity that DMD has three interfaces
to va_arg - X86, X86_64, and Win64).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';



 Dec 22 2013



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Iain Buclaw:


 For inline assembly, making dmd work better how?


I meant making dmd better in general. Faster floating point, more
optimization tricks, etc.



 Not possible without some sort of translation map, which would 
 be target
 specific, so not suitable for GDC, and language specific so not 
 suitable for GCC either.

 Also, falls under category of x86-centric below.


Did you express such problems during the design phase of that
recent language feature?

Bye,
bearophile



 Dec 23 2013



  parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 23 December 2013 11:05, bearophile <bearophileHUGS lycos.com> wrote:

 Iain Buclaw:



 For inline assembly, making dmd work better how?



 I meant making dmd better in general. Faster floating point, more
 optimization tricks, etc.




 Not possible without some sort of translation map, which would be target
 specific, so not suitable for GDC, and language specific so not suitable
 for GCC either.

 Also, falls under category of x86-centric below.



 Did you express such problems during the design phase of that
 recent language feature?


I'll answer that with a question. Did you really think that __simd
went through a design phase? :-)



 Dec 23 2013



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Iain Buclaw:

Did you really think that __simd went through a design phase? :-)

I understand. So there is still a problem bigger than __simd.

Bye,
bearophile



 Dec 23 2013



 next sibling parent  Manu <turkeyman gmail.com>  writes:


On 23 December 2013 22:06, bearophile <bearophileHUGS lycos.com> wrote:


 Iain Buclaw:


 Did you really think that __simd went through a design phase? :-)

 I understand. So there is still a problem bigger than __simd.


To be fair, I don't think this is as significant as it sounds. I agree,
__simd had no real design, it was just a convenient implementation for DMD,
but isn't that always the case for compiler intrinsics? In most cases, LLVM
tries to mirror GCC intrinsics, but there are many significant distinctions
between LLVM and GCC's intrinsics, making versions in the code for each
compiler there too.
In my experience, there is always versioning issues when making use of
compiler intrinsics, what's important is that the language is able to wrap
them up cleanly and effectively. D currently satisfies this requirement to
some extent, but in my experience with std.simd, to get to the 100% mark, I
really need __forceinline. I can't really finish std.simd to a satisfactory
level without it.



 Dec 23 2013



prev sibling next sibling parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 23 December 2013 23:02, Manu <turkeyman gmail.com> wrote:

 On 23 December 2013 22:06, bearophile <bearophileHUGS lycos.com> wrote:

 Iain Buclaw:


 Did you really think that __simd went through a design phase? :-)

 I understand. So there is still a problem bigger than __simd.



 To be fair, I don't think this is as significant as it sounds. I agree,
 __simd had no real design, it was just a convenient implementation for DMD,
 but isn't that always the case for compiler intrinsics? In most cases, LLVM
 tries to mirror GCC intrinsics, but there are many significant distinctions
 between LLVM and GCC's intrinsics, making versions in the code for each
 compiler there too.
 In my experience, there is always versioning issues when making use of
 compiler intrinsics, what's important is that the language is able to wrap
 them up cleanly and effectively. D currently satisfies this requirement to
 some extent, but in my experience with std.simd, to get to the 100% mark, I
 really need __forceinline. I can't really finish std.simd to a satisfactory
 level without it.


We have an  attribute("forceinline") for that... :o)

And sorry, but some compiler intrinsics for DMD really do just shoot
themselves in the foot.



 Dec 23 2013



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 24 December 2013 09:37, Iain Buclaw <ibuclaw gdcproject.org> wrote:


 On 23 December 2013 23:02, Manu <turkeyman gmail.com> wrote:

 On 23 December 2013 22:06, bearophile <bearophileHUGS lycos.com> wrote:

 Iain Buclaw:


 Did you really think that __simd went through a design phase? :-)

 I understand. So there is still a problem bigger than __simd.



 To be fair, I don't think this is as significant as it sounds. I agree,
 __simd had no real design, it was just a convenient implementation for


 DMD,

 but isn't that always the case for compiler intrinsics? In most cases,


 LLVM

 tries to mirror GCC intrinsics, but there are many significant


 distinctions

 between LLVM and GCC's intrinsics, making versions in the code for each
 compiler there too.
 In my experience, there is always versioning issues when making use of
 compiler intrinsics, what's important is that the language is able to


 wrap

 them up cleanly and effectively. D currently satisfies this requirement


 to

 some extent, but in my experience with std.simd, to get to the 100%


 mark, I

 really need __forceinline. I can't really finish std.simd to a


 satisfactory

 level without it.


 We have an  attribute("forceinline") for that... :o)


DMD doesn't, which is where it's needed the most >_<
Ideally, this needs to be standardised, so compiler-specific intrinsics can
be properly wrapped up.


And sorry, but some compiler intrinsics for DMD really do just shoot

 themselves in the foot.


Perhaps, but I'm able to make do with __simd in this case... at least, if I
could wrap it effectively.



 Dec 23 2013



  parent  Jacob Carlborg <doob me.com>  writes:


On 2013-12-24 01:30, Manu wrote:


 DMD doesn't, which is where it's needed the most >_<
 Ideally, this needs to be standardised, so compiler-specific intrinsics
 can be properly wrapped up.


Perhaps you might be able to finish the implementation with GDC. You can 
sill use  attribute("forceinline") to compile on DMD as well, but it 
won't to anything, obviously.

-- 
/Jacob Carlborg



 Dec 27 2013



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2013-12-22 22:30, Iain Buclaw wrote:


 While useful the ability to write inline assembler functions, DMD
 can't inline these around the place. So you get all the benefits of
 being able to shortcut the fastest route to do X, but with the
 slowdown of 25% because there's a big elephant in the room.


I'm not talking about any specific compiler. I also wrote this post[1], 
which is more in line of with what GDC and LDC provides.

[1] 
http://forum.dlang.org/thread/mailman.28.1387438018.2938.digitalmars-d puremagic.com?page=3#post-l943eg:24170f:241:40digitalmars.com

-- 
/Jacob Carlborg



 Dec 23 2013



prev sibling  parent reply Russel Winder <russel winder.org.uk>  writes:


On Fri, 2013-12-20 at 22:05 +0100, Jacob Carlborg wrote:
[=E2=80=A6]

 When developing an OS, for somethings these languages are not enough,=20
 including C, Go and D. You need to use assembly. D has the advantage of=


=20

 supporting inline assembly.


C, C++, Go, D have the advantage of using separate files with the
assembly code in.

Inline assembly language is a huge disadvantage in many (most?) case.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Dec 21 2013



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2013-12-21 11:14, Russel Winder wrote:


 Inline assembly language is a huge disadvantage in many (most?) case.


I don't know. Would you like to move all the current inline assembly in 
druntime to their own files? I don't use assembly myself but it seems 
convenient to have support for inline assembly for use cases like in 
druntime. Most inline assembly in drunimte only consists of 1-10 lines 
of code.

-- 
/Jacob Carlborg



 Dec 21 2013



 next sibling parent reply Russel Winder <russel winder.org.uk>  writes:


On Sat, 2013-12-21 at 14:03 +0100, Jacob Carlborg wrote:

 On 2013-12-21 11:14, Russel Winder wrote:
=20

 Inline assembly language is a huge disadvantage in many (most?) case.


=20
 I don't know. Would you like to move all the current inline assembly in=


=20

 druntime to their own files? I don't use assembly myself but it seems=20
 convenient to have support for inline assembly for use cases like in=20
 druntime. Most inline assembly in drunimte only consists of 1-10 lines=


=20

 of code.


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.

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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Dec 21 2013



 next sibling parent reply "Araq" <rumpf_a web.de>  writes:


 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.


No, that's a completely orthogonal issue: You can easily have 
architecture dependent code in separate modules.

The point of an inline assembler is that the compiler knows 
things like field offsets and so can provide useful features no 
external assembler can. It can also inline the assembler code 
eliminating any function call overhead. Your ignorance doesn't 
make these things misfeatures.



 Dec 21 2013



  parent  Russel Winder <russel winder.org.uk>  writes:


On Sat, 2013-12-21 at 20:18 +0100, Araq wrote:
[=E2=80=A6]

 The point of an inline assembler is that the compiler knows=20
 things like field offsets and so can provide useful features no=20
 external assembler can. It can also inline the assembler code=20
 eliminating any function call overhead. Your ignorance doesn't=20
 make these things misfeatures.


and your lack of courteous commentary makes debate with you a waste of
both our time.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Dec 21 2013



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.


 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.



 Dec 21 2013



  parent reply Russel Winder <russel winder.org.uk>  writes:


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.


=20
 You can still put D inline assembly in separate files. What you don't nee=


d is an=20

 assembler.


But this implies the D compiler has to be able to handle Intel, Sparc,
AMD, ARM, ARM Thumb, Atmel, =E2=80=A6 Certainly compiler code generators ha=
ve 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.=20


 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.


=20
 There is no case where D's support for intel inline assembler is worse th=


an=20

 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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Dec 22 2013



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/22/2013 12:05 AM, Russel Winder wrote:

 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.



That is a good point and I definitely agree.

But I don't think this has much to do with inline assembler support - and 
supporting an assembler for ARM is simply not that hard. There's nothing tricky 
about an assembler or its syntax. There may be issues with supporting an inline 
assembler and the GDC or LDC back end interfaces, that I don't know about.



 Dec 22 2013



  parent  "David Nadlinger" <code klickverbot.at>  writes:


On Sunday, 22 December 2013 at 17:21:59 UTC, Walter Bright wrote:

 There's nothing tricky about an assembler or its syntax. There 
 may be issues with supporting an inline assembler and the GDC 
 or LDC back end interfaces, that I don't know about.


Both GCC and LLVM actually support more extensive inline assembly 
than DMD does (allowing to explicitly specify side effects so the 
respective piece of code can still be optimized/inlined).

David



 Dec 22 2013



prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org>  writes:


On 21.12.2013 14:03, Jacob Carlborg wrote:

 On 2013-12-21 11:14, Russel Winder wrote:


 Inline assembly language is a huge disadvantage in many (most?) case.


 I don't know. Would you like to move all the current inline assembly in
 druntime to their own files? I don't use assembly myself but it seems
 convenient to have support for inline assembly for use cases like in
 druntime. Most inline assembly in drunimte only consists of 1-10 lines
 of code.


Personally I rather use powerful external macro assemblers like 
NASM/MASM than inline assemblers, as I mentioned a few times here.

Specially since most inline assemblers I used tend to be rather limited 
in comparison.


--
Paulo



 Dec 21 2013



  parent  "ponce" <contact g3mesfrommars.fr>  writes:


 Personally I rather use powerful external macro assemblers like 
 NASM/MASM than inline assemblers, as I mentioned a few times 
 here.

 Specially since most inline assemblers I used tend to be rather 
 limited in comparison.


Actually DMD might be the most powerful macro assembler out there:

     import std.stdio;
     import std.conv;

     int test(int Result)()
     {
         asm { naked; }
         mixin(r"
         asm
         {
             mov EAX, " ~ to!string(Result) ~ r";
             ret;
         }"
         );
     }

     void main()
     {
         writefln("%s", test!4());
         writefln("%s", test!5());
     }



 Dec 21 2013



prev sibling  parent  Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


On 21/12/13 15:44, 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.

 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.


That surely depends on your use-case.  There must be situations in embedded 
programming where it's useful to be able to just put in a handful of lines of 
assembly, and where there's no portability issue to cause you to get lost in a 
maze of conditionals.



 Dec 22 2013



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Saturday, 21 December 2013 at 10:14:32 UTC, Russel Winder 
wrote:

 C, C++, Go, D have the advantage of using separate files with 
 the
 assembly code in.

 Inline assembly language is a huge disadvantage in many (most?) 
 case.


Depends, it allows you to add support for locking-mechanisms/SIMD 
instructions/etc before getting language support. You want that 
inlined and the compiler to do register assignment. I believe 
LLVM just pass it on to the assembler almost verbatim. If done 
right you wouldn't need to update the compiler in order to add 
support for new instructions/trap mechanisms, updating an 
external assembler should be sufficient, so it is a future-proof 
technology. I think inline asm wrapped up as inline functions is 
pretty neat, in the rare case where you need it (some rare CPUs 
have built in true random() functionality for instance).



 Dec 21 2013



  parent reply Russel Winder <russel winder.org.uk>  writes:


On Sun, 2013-12-22 at 04:48 +0000, Ola Fosheim =3D?UTF-8?B?R3LDuHN0YWQi?=3D=
=20
[=E2=80=A6]

 Depends, it allows you to add support for locking-mechanisms/SIMD=20
 instructions/etc before getting language support. You want that=20
 inlined and the compiler to do register assignment. I believe=20
 LLVM just pass it on to the assembler almost verbatim. If done=20
 right you wouldn't need to update the compiler in order to add=20
 support for new instructions/trap mechanisms, updating an=20
 external assembler should be sufficient, so it is a future-proof=20
 technology. I think inline asm wrapped up as inline functions is=20
 pretty neat, in the rare case where you need it (some rare CPUs=20
 have built in true random() functionality for instance).


Historically, and anecdotally, I found that as soon as the assembly
language was a function, it was better as a separate entity, that inline
assembler only worked for accessing a processor instruction that the
code generator could not generate. So I think you are making this same
point, cf. SIMD instructions at the bleeding edge.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Dec 22 2013



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Sunday, 22 December 2013 at 08:11:05 UTC, Russel Winder wrote:

 Historically, and anecdotally, I found that as soon as the 
 assembly
 language was a function, it was better as a separate entity,


Well, you can usually get what you want by first writing the code 
in C, then generate asm and optimize that by hand. So, being able 
to generate useful asm listings is more important than inlining, 
I think. In that respect I agree. I would much rather have the 
ability to generate tight and readable/auto-commented ASM than 
having inlining.


 that inline
 assembler only worked for accessing a processor instruction 
 that the
 code generator could not generate. So I think you are making 
 this same
 point, cf. SIMD instructions at the bleeding edge.


Well, yes, but if you are doing projects where you know the 
hardware and the hardware is specialized and limited (e.g. tiny 
amounts of RAM/ROM, no division/multiply, System on a Chip etc) 
it becomes a little bit more attractive to be able to do asm here 
and there: get the most out of flag-registers (like carry, 
overflow etc), run without an OS and write tight IRQ handlers. 
Like art-installations, small robots, embedded things? Granted, 
this is not something D is suitable for atm, but I hope it will 
move in that direction, eventually. I think it could become a hit.

Regarding bleeding edge: AFAIK, inlined asm is necessary if you 
want to benefit effectively from transactional memory in Haswell 
processors today, although it would be much much more convenient 
with language support. It is hard to get right, because there are 
cache-line restrictions (objects have a minimum/maximum size, so 
you have to group attributes that are to be protected into the 
same region). I think inline asm might be useful in a heavily 
optimized single-purpose server for that reason. But to 
conveniently benefit from that the compiler have to generate ASM 
that the CPU-vendor's assembler can parse and without 
restrictions on instructions unknown to the compiler (so you 
don't have to resort to injecting opcodes rather than mnemonics). 
If inline asm implies a built in assembler then I am not at all 
sure if it is all that useful.



 Dec 22 2013



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/22/2013 12:10 AM, Russel Winder wrote:

 Historically, and anecdotally, I found that as soon as the assembly
 language was a function, it was better as a separate entity, that inline
 assembler only worked for accessing a processor instruction that the
 code generator could not generate. So I think you are making this same
 point, cf. SIMD instructions at the bleeding edge.


What blows about most assemblers I've had the misfortune to work with is that 
they did not understand C structs.

This means when you write assembler code that interfaces with your C project, 
you have to duplicate the C .h files in the assembler's peculiar syntax. Make a 
mistake, and you've got instant memory corruption. Someone changes a C .h 
header, instant corruption again.

It's a maintenance nightmare, and wholly unnecessary. Apparently nobody writing 
an assembler ever had the obvious idea of tacking on a C front end so it could 
at least pull the struct declarations out of the .h files.



 Dec 22 2013



  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Walter Bright:


 Apparently nobody writing an assembler ever had the obvious 
 idea of tacking on a C front end so it could at least pull the 
 struct declarations out of the .h files.


In D you can do the opposite: write the asm files, import them 
statically from D and parse and convert them with compile-time 
code into D struct defintions :-)



 There may be issues with supporting an inline assembler and the 
 GDC or LDC back end interfaces, that I don't know about.


I think GDC and LDC developers are willing to give you answers on 
this, if you ask.

Bye,
bearophile



 Dec 22 2013