Xref: news2.mv.net comp.graphics.algorithms:20758 comp.os.msdos.djgpp:4174
From: simonh AT ic DOT ac DOT uk (Dr S.J. Harris)
Newsgroups: comp.os.msdos.djgpp,comp.graphics.algorithms
Subject: Re: Inline ASM, Mode 13h problem
Date: 22 May 1996 16:52:43 GMT
Organization: Imperial College of Science, Technology and Medicine, London
Lines: 51
Message-ID: <4nvgor$8dk@oban.cc.ic.ac.uk>
References: <31A26377 DOT 29C6 AT postoffice DOT ptd DOT net> <4nva9j$5l5 AT wapping DOT ecs DOT soton DOT ac DOT uk>
NNTP-Posting-Host: cvcgf.cv.ic.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <4nva9j$5l5 AT wapping DOT ecs DOT soton DOT ac DOT uk> rjc94 AT ecs DOT soton DOT ac DOT uk (Robert Cooper) writes:
>
>>void putpixel(short x,short y,short c) {
>>  __asm__ __volatile__("
>>    movw %0, %%es;
>>    movl $0xA0000, %%edi;
>>    movw %2, %%ax;
>>    imulw $320, %%ax;
>>    addw %1, %%ax;
>>    addw %%ax, %%di;
>>    movb %3, %%es:(%%edi);"
>>    :
>>    : "g" (glib_selector), "g" (x), "g" (y), "g" (c)
>>    );
>>I'm developing under RHIDE beta4.  I get an assembler error in the 
>>putpixel function, and I believe it is with the following line:  
>>	movb %3, %%es:(%%edi);"  
>
>>ERROR:  OPERANDS GIVEN DON'T MATCH ANY KNOWN 386 INSTRUCTION.
>
>Hmm.  Shouldn't those commands be something like movsb/movsw.  Rather 
>than movb/movw.  I think that may be right, but then again, I don't know 
>a huge amount about ASM either.
>
>Ica

I don't know this particular assembler either, although from the code
example, it is obvious that the format is more closely related to
PDP and Motorola assembly code than the Intel standard, so I suspect
that movb is correct for 'Move byte'. However, the problem, I think,
is that you are trying to give a source and destination as memory
addresses (one, the colour is probably a BP relative address, the other
- the screen address - indexed via edi). Now, AFAIK, moves can be
memory->register, register->register, register->memory, immediate -> either
so you probably need to split your line into two. Try the following

	movb %3,%%al ;              get that colour into al
	movb %%al,%%es:(%%edi) ;    and now write it to the screen

(in standard Intel format, this would be
    MOV AL,<param3>     -  however the 3rd C parameter is recovered 
    MOV ES:[EDI],AL
)

Hope this helps (although we are straying somewhat away from the
territory of graphics algorithms)

Regards,

Simon.