On Wed, Jul 31, 2013 at 05:07:26PM +0200, Dicebot wrote:
> On Wednesday, 31 July 2013 at 14:58:24 UTC, H. S. Teoh wrote:
> >	People who are more than casually interested in computers should
> >	have at least some idea of what the underlying hardware is like.
> >	Otherwise the programs they write will be pretty weird.
> >	-- D. Knuth
> 
> Well, while I do agree in general, there is a huge difference between understanding how h/w executes machine code and casually reading assembly listings ;)

I still find the ability to read machine code invaluable when debugging, esp. when trying to determine the cause of segfaults. At least at my day job, segfaults do log a stacktrace to a crash log, but there is no core dump, and on customer installations, there are no debugging symbols either, so all you have is a list of register values and stack return addresses. Being able to map that to the code by reading the disassembly of the executable allows you to pinpoint the cause of the problem, which otherwise would take many days of building and rebuilding test images, or worse, if the problem is only intermittent, it might take 5 months before QA is able to reproduce the problem reliably.

In the past month or so, I've fixed at least two bugs this way, one of which only happens in a very specific network congestion state that it's pretty much impossible to reproduce without knowing what the problem was. Reading the disassembly allowed me to determine exactly which statement was dereferencing a null pointer, so that later, when I was tracing through the execution path, I immediately recognized a particular race condition that would trigger the precise symptoms I observed.

Plus, I've identified the cause of a handful DMD wrong-code bugs by reading the disassembly of said wrong code. ;-) It's a pity I don't have the time to familiarize myself with DMD internals, otherwise I'd submit bug fixes too.


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all I can take." -- Calvin & Hobbes

On Wed, Jul 31, 2013 at 05:08:01PM +0200, Joseph Rushton Wakeling wrote:
> On 07/31/2013 04:56 PM, H. S. Teoh wrote:
> > It's completely worth the effort though, IMO.
> 
> It will mean I can finally talk programming with my dad, who _only_ knows how to program in assembly (and still does so regularly:-)

Really? There's still a market for that stuff? I want in! ;-)


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

On Wednesday, 31 July 2013 at 15:07:28 UTC, Dicebot wrote:
> On Wednesday, 31 July 2013 at 14:58:24 UTC, H. S. Teoh wrote:
>> 	People who are more than casually interested in computers should
>> 	have at least some idea of what the underlying hardware is like.
>> 	Otherwise the programs they write will be pretty weird.
>> 	-- D. Knuth
>
> Well, while I do agree in general, there is a huge difference between understanding how h/w executes machine code and casually reading assembly listings ;)

I disagree. There is nothing in asm except how the machine works (plus a few convenience features e.g. not having to read actual opCodes in octal/hex). If you understand how the h/w works then you understand assembly code. It would simply be a matter of getting used to the notation.

Plus, I would argue that learning assembly is a great path to understanding the machine itself. To be honest I can't imagine it any other way.

On Wednesday, 31 July 2013 at 12:01:43 UTC, JS wrote:
> I don't think D's code generation is even close to being as mature as many of the common C++ compilers.

dmd's code generation isn't as good as e.g. gcc/clang/icc

ldc and gdc use the clang and gcc backends respectively and therefore, by definition, benefit from the same code generation.

On Wed, Jul 31, 2013 at 06:08:23PM +0200, John Colvin wrote:
> On Wednesday, 31 July 2013 at 12:01:43 UTC, JS wrote:
> >I don't think D's code generation is even close to being as mature as many of the common C++ compilers.
> 
> dmd's code generation isn't as good as e.g. gcc/clang/icc
> 
> ldc and gdc use the clang and gcc backends respectively and therefore, by definition, benefit from the same code generation.

Keep in mind, that the clang and gcc backends have *huge* teams of developers contributing their expertise to improve the respective optimizers, whereas there are significantly fewer people working on dmd's optimizer.  No matter how skill Walter is (and I don't doubt his skill -- I mean, just look at D), he can only do so much as one person.


T

-- 
Political correctness: socially-sanctioned hypocrisy.