• llee (12/12) Jul 22 2006 I've been working with the inline assembler for the past few weeks, tryi...
• Mike Parker (12/26) Jul 22 2006 Inline assembly is called 'inline' exactly because it is intended to be
• Tim Starling (22/34) Jul 22 2006 It sounds like you're a bit out of date. You want to be using DirectX, n...

llee <llee_member pathlink.com> writes:

I've been working with the inline assembler for the past few weeks, trying to
learn the in's and out's of assembly code. I've managed to gain a basic
understanding of it's syntax, but a major question still remains; what can it be
used for? Over this time period I've spent a lot of time reviewing other
programs and code. Every one of them seem to rely on interrupts services. Yet
everytime I try to use these services I find myself commiting an 'access
violation'. If windows no longer provides access to bios and dos services, how
can user input be accessed, or output displayed? If a programmer is forced to
use the standard D input  and output functions with assembly code intersparsed,
what advantage does it have over pure D code? 
I'm looking to gain something from using assembly, but I'm not sure that there's
anything worth while. 

Mike Parker <aldacron71 yahoo.com> writes:

llee wrote:
 I've been working with the inline assembler for the past few weeks, trying to
 learn the in's and out's of assembly code. I've managed to gain a basic
 understanding of it's syntax, but a major question still remains; what can it
be
 used for? Over this time period I've spent a lot of time reviewing other
 programs and code. Every one of them seem to rely on interrupts services. Yet
 everytime I try to use these services I find myself commiting an 'access
 violation'. If windows no longer provides access to bios and dos services, how
 can user input be accessed, or output displayed? If a programmer is forced to
 use the standard D input  and output functions with assembly code intersparsed,
 what advantage does it have over pure D code? 
 I'm looking to gain something from using assembly, but I'm not sure that
there's
 anything worth while. 
 
 

Inline assembly is called 'inline' exactly because it is intended to be 
interspersed with your D (or C, or C++, or any other language that 
supports it) code. If someone wanted to write a pure assembly program, 
why would you do so with a D compiler?

The idea behind inline assembly is primarily one of optimization. While 
most optimization should be done at the algorithmic level, there are 
times when that is not enough. For example, you can't use MMX, SSE, 
SSE2, and such directly from D code. In order to get at those, you have 
to use assembly. There may be other times when algorithmic optimization 
doesn't result in the performance you need, or maybe the compiler isn't 
putting out efficient instructions for a performance critical block of code.

Tim Starling <tstarling wikimedia.org> writes:

llee wrote:
 I've been working with the inline assembler for the past few weeks, trying to
 learn the in's and out's of assembly code. I've managed to gain a basic
 understanding of it's syntax, but a major question still remains; what can it
be
 used for? Over this time period I've spent a lot of time reviewing other
 programs and code. Every one of them seem to rely on interrupts services. Yet
 everytime I try to use these services I find myself commiting an 'access
 violation'. If windows no longer provides access to bios and dos services, how
 can user input be accessed, or output displayed? If a programmer is forced to
 use the standard D input  and output functions with assembly code intersparsed,
 what advantage does it have over pure D code? 
 I'm looking to gain something from using assembly, but I'm not sure that
there's
 anything worth while. 

It sounds like you're a bit out of date. You want to be using DirectX, not 
INT 10H. I haven't personally done any I/O in assembly since the days of 
BIOS and DOS software interrupts, but I imagine if you obtained a surface 
pointer with DirectDraw and wrote to it with an assembly routine, then you 
could obtain much the same speedup factor as in the olden days of writing to 
CGA memory at B800:0000. I've seen tutorials on calling the Windows API from 
assembly, but personally I'd rather leave that sort of tedium to the 
compiler, since I doubt there'd be much to gain.

I agree with Mike that assembly should primarily be used for the 
optimisation of hotspots. It's tricky business though, in my experience, 
optimising for a modern processor with a long pipeline and a significant 
cache miss delay can be very counterintuitive. It's not enough to just count 
cycles like we did in the 286 days.

However, if you can use assembly to access SSE/SSE2 instructions instead of 
387, then you can get a speed improvement on a Pentium 4 with your eyes 
closed. Every compiler should support them. This is probably a good 
opportunity to bring attention to these comments I made on floating point 
optimisation, maybe 18 months ago:

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float

Only the signed comment is mine.

-- Tim Starling