[net.micro.pc] REP vs. REPZ - I goofed.

hhoeksma@watmath.UUCP (Henry Hoeksma) (08/08/85)

Thanks to all those who pointed out that REP and REPZ are the same
prefix.  I was fooled by the Intel guide "8086 ... Programmer's Pocket
Reference Guide, (C) 1980, 1982" which states on page 43 that the 
opcode for a REP is #F2 and for REPZ it is #F3.  This is wrong.  In
fact, the same manual has the correct numbers (including REPNZ) on
page 25.
   My appologies to MicroSoft and Lattice.  I (and others) are still
having difficulties with movmem(), but the cause is as yet unknown.
-Henry

bc@cyb-eng.UUCP (Bill Crews) (08/12/85)

>    My appologies to MicroSoft and Lattice.  I (and others) are still
> having difficulties with movmem(), but the cause is as yet unknown.
> -Henry

Be aware that, as of Lattice C 2.15, movmem() does NOT preserve the contents
of the ES register!  If you are using the small model, Lattice expects ES
to be preserved across function invocations.  Lattice, Inc:  take note!
-- 
  /  \    Bill Crews
 ( bc )   Cyb Systems, Inc
  \__/    Austin, Texas

[ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc

matt@prism.UUCP (08/14/85)

> /* Written  2:10 am  Aug 12, 1985 by bc@cyb-eng in prism:net.micro.pc */
> >    My appologies to MicroSoft and Lattice.  I (and others) are still
> > having difficulties with movmem(), but the cause is as yet unknown.
> > -Henry
> 
> Be aware that, as of Lattice C 2.15, movmem() does NOT preserve the contents
> of the ES register!  If you are using the small model, Lattice expects ES
> to be preserved across function invocations.  Lattice, Inc:  take note!
> -- 
> /* End of text from prism:net.micro.pc */

Note that MANY of the Lattice standard I/O routines have this problem,
including peek(), intdos(), and bdos().  This is a real loss if you are
using any of the DOS services that return vectors in ES:BX.

Is there anyone from Lattice on the net, now that they have a Unix box?

-----------------------------------------------------------------------------
 Matt Landau            {cca, datacube, ihnp4, inmet, mit-eddie, wjh12}...
 Mirror Systems, Inc.                                   ...mirror!prism!matt
 Cambridge, MA		(617) 661-0777
-----------------------------------------------------------------------------
 "Replace this mandolin with your wombat..."

peter@baylor.UUCP (Peter da Silva) (08/19/85)

> > Be aware that, as of Lattice C 2.15, movmem() does NOT preserve the contents
> > of the ES register!  If you are using the small model, Lattice expects ES
> > to be preserved across function invocations.  Lattice, Inc:  take note!
> > -- 
> > /* End of text from prism:net.micro.pc */
> 
> Note that MANY of the Lattice standard I/O routines have this problem,
> including peek(), intdos(), and bdos().  This is a real loss if you are
> using any of the DOS services that return vectors in ES:BX.
> 
> Is there anyone from Lattice on the net, now that they have a Unix box?

Aha! I have a problem where I'm trying to use "intdos" to do filename expansion
in _main() so that I get a nice expanded argv in main(). It works but it breaks
stdio. Has anyone got an intdos that fixes this? ALSO: why can't INTDOS have
the following calling protocol:

	int intdosx(regs, segregs)
	union REGS *regs;
	struct SREGS *segregs;

regs & segregs are both input and output. Result is the 8086 flags word. This
way you wouldn't need two buffers for REGS (I generaly call it with inregs
and outregs pointing to the same strcture), and you could get the resulting
ES register? Maybe someone could post a better version of intdos, int86,
intdosx, and int86x... Lattice? Lifeboat? DO you hear me?
-- 
	Peter (Made in Australia) da Silva
		UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
		MCI: PDASILVA; CIS: 70216,1076

lotto@talcott.UUCP (Jerry Lotto) (08/20/85)

	This discussion has veered way off track from REP vs. REPZ.
Have pity on those of us without the latest rn and EDIT the subject
line when appropriate.
-- 

Gerald Lotto - Harvard Chemistry Dept.

 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
 ARPA:  lotto@harvard.ARPA
 CSNET: lotto%harvard@csnet-relay