Intel 8086 opcodes - CP/M

This is a discussion on Intel 8086 opcodes - CP/M ; On Sep 13, 9:29 am, roche...@laposte.net wrote: > My first feeling was to remove the "signed byte" distinction, and to > replace it with "byte". > > But, then, of course, the sign bit would not be "extended"... > > ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 65 of 65

Thread: Intel 8086 opcodes

  1. Re: Intel 8086 opcodes

    On Sep 13, 9:29 am, roche...@laposte.net wrote:

    > My first feeling was to remove the "signed byte" distinction, and to
    > replace it with "byte".
    >
    > But, then, of course, the sign bit would not be "extended"...
    >
    > Damned! All that for 5 bytes out of 40 K! As I said, I could not find
    > any instance of a "signed byte" anywhere else in the Intel doc. (It
    > would be funny to ask this question to some "gurus"...)
    >
    > Opinions welcomed.
    >
    > Yours Sincerely,
    > Mr Emmanuel Roche


    Here's an opinion: Roche is not acting in good faith, he's posting to
    show off. Why support that with a reply? If you read this and already
    agree with me, you don't need to read further. If you disagree, read
    on, I'll make the case. - Herb Johnson

    Actually, Roche did NOT welcome an opinion on this subject. Namely, MY
    opinion which I sent him privately. I read the manual in question
    myself, I have a copy. After some hours of work (it's been years since
    I programmed the 8086) I sent a number of detailed notes to explain
    where this instruction mode is described IN THAT MANUAL. His brief
    response: "I don't think you should try to be a programmer; stick to
    your S-100 work".

    While I don't claim to be a programming "guru", I think that a BSEE
    degree from the 70's and years of professionally programming Intel
    processors in that period, qualify me as being able to AT LEAST read
    the same Intel manual that Roche has so much trouble reading.

    My reply to him, showed him places in that Intel "8086 Family Guide",
    where the signed byte instruction is discussed. Not at length and not
    transparently, but it's there. Many of his issues about the manual are
    about a pair of SUMMARY tables ON ONE PAGE. They are only that, a
    summary, of about 18 pages of two instruction charts which are more
    complete, supported further by several pages of text and other small
    tables. While I no longer follow his posts in detail, I guess he is
    rediscovering that text over time.

    The fact that Intel's manuals of the 70's are not easy reading is well
    known. As for the difficulties of dealing with BYTE vs WORD
    references, I had simply forgotten all those irregularities until I
    reviewed the manual. But that's why manuals are written, to be read a
    few times, not once; and if one manual is insufficient, one reads
    another. This is called a "learning curve"; watching Roche's is to me
    rather tedious, seperate from his insult to me.

    I also suggested to Roche that he use a debugger to check these op
    codes. Then he did, no thanks given. I did not think it was necessary
    to explain HOW to use it. Mostly he's used it as an assembler, or to
    poke a few op codes in, or a list of op codes, to see how they
    assembled. He's not used it to actually EXECUTE some code, to see what
    operands actually make it into registers. I did not think I had to
    explain that - "here's how you run code". But I simply can't keep
    track of whether he's actually TRIED to poke in, in hex, an
    appropriate ADD instruction with a negative byte-sized value! He rants
    about this instruction feature, but doesn't really exercise it fully.

    And, even when assembling or disassembing, he simply MISCOUNTS the
    number of bytes used! Or posts partial results, so I had to guess that
    byte count. When that's your argument, miscounting is just sloppy
    work, and not showing the hex with the assembly listing is poor work.
    I have no time to correct flawed work, does anyone else?

    In short, Roche's posts are inaccurate, incomplete, and are only
    impressive from the sheer volume he is able to generate. He's on a
    learning curve - why does the world have to watch it? As for content
    posted: throw enough mud, something sticks - there is some fallout
    worth some discussion by those who actually KNOW 8086 operation. Those
    who reply have informative things to say. But why support THIS means
    of generating such discussion?

    I am reluctantly posting this as I don't care to post personal
    comments about others. But the alternatives are either to say nothing
    and let the thread die - which probably won't happen for weeks. Or, to
    post corrections to Roche's posts - but at his posting rate I simply
    lack time to do so. Also, it "feeds" his desire to post more. Finally,
    as he's insulted and offended me personally AND professionally, I have
    no inclination to reply to him.

    And all THAT is why I decided to post this warning. In my opinion,
    this thread is not about someone who is trying to learn 8086 assembly
    language or processor operations, and asking for help. It's about
    someone who sees a way to use other's good intentions to run a long
    LONG thread for his own VANITY. That defines a TROLL.

    If you don't agree, I won't argue about it - I'm no troll looking for
    a fight. But if Roche can post TWENTY ONE TIMES in three weeks on a
    vanity thread, maybe I'm allowed one post in protest.

    Herb Johnson

    Herbert R. Johnson, New Jersey USA
    http://www.retrotechnology.com/herbs_stuff/ web site
    http://www.retrotechnology.net/herbs_stuff/ domain mirror
    my email address: hjohnson AAT retrotechnology DOTT com
    if no reply, try in a few days: herbjohnson ATT comcast DOTT net
    "Herb's Stuff": old Mac, SGI, 8-inch floppy drives
    S-100 IMSAI Altair computers, docs, by "Dr. S-100"


  2. Re: Intel 8086 opcodes

    Hello, Herb!

    > (...)Finally,
    > as he's insulted and offended me personally AND professionally, I have
    > no inclination to reply to him.


    I am terribly sorry to learn indirectly, publicly via the comp.os.cpm
    Newsgroup, that you felt insulted by my one-line reply. You had sent
    me 3 long messages about the difference between the 82 and 83 opcodes,
    and my last message (at that time) listed the hex opcodes, along with
    an explanation of them. (The problem was not what was written in the
    Intel doc, but how to generate them with ASM-86).

    > And all THAT is why I decided to post this warning. In my opinion,
    > this thread is not about someone who is trying to learn 8086 assembly
    > language or processor operations, and asking for help. It's about
    > someone who sees a way to use other's good intentions to run a long
    > LONG thread for his own VANITY. That defines a TROLL.


    I don't know if I am trying to learn 8086 assembly language. All I
    know is that I have disassembled ASM-86 Version 1.1, am now checking
    all the "legal" 8086 opcodes, and will (hopefully) disassemble SID-86,
    so as to have a complete 8086 assembly language development system
    running under CP/M-86 Plus. Once it will be done, I will see if I make
    a 386 version (only the tables inside ASM-86 would need to be updated,
    since it is a table-driven assembler).

    I am sorry if you felt that they were long posts, but I made them
    along the way, as I discovered bugs. The last listings (all the
    opcodes, then only the FF opcodes) are now my basis for further work.
    I have now understood the purposes of some groupings of instructions,
    and discovered some "secondary opcodes" used only once. I guess that
    they were probably used in later Intel processors. I would need a
    table listing all the additions to the 8086 instruction set (mnemonics
    and opcodes) for each newer CPUs. If someone knows if such a table
    exists, this would help me fill the unused secondary opcodes, thus
    helping me to make a 386 assembler running under CP/M (-86 Plus).

    Yours Sincerely,
    Mr Emmanuel Roche



  3. Re: Intel 8086 opcodes

    On Tue, 18 Sep 2007 09:14:15 -0700, Herb Johnson
    wrote:

    >Subject: Re: Intel 8086 opcodes
    >
    >On Sep 13, 9:29 am, roche...@laposte.net wrote:
    >
    >> My first feeling was to remove the "signed byte" distinction, and to
    >> replace it with "byte".
    >>
    >> But, then, of course, the sign bit would not be "extended"...
    >>
    >> Damned! All that for 5 bytes out of 40 K! As I said, I could not find
    >> any instance of a "signed byte" anywhere else in the Intel doc. (It
    >> would be funny to ask this question to some "gurus"...)
    >>
    >> Opinions welcomed.
    >>
    >> Yours Sincerely,
    >> Mr Emmanuel Roche

    >
    >Here's an opinion: Roche is not acting in good faith, he's posting to
    >show off. Why support that with a reply? If you read this and already
    >agree with me, you don't need to read further. If you disagree, read
    >on, I'll make the case. - Herb Johnson



    Well said!

  4. Re: Intel 8086 opcodes

    Herb Johnson wrote:

    (snip)

    > Here's an opinion: Roche is not acting in good faith, he's posting to
    > show off. Why support that with a reply? If you read this and already
    > agree with me, you don't need to read further. If you disagree, read
    > on, I'll make the case. - Herb Johnson


    That is possible.

    It might also be true for 90% of the posts to newsgroups.

    It does seem that he really wants the answer, though it might
    be that he could use a different posting style. Also, that he
    is a little slower at understanding than some of us.

    I don't know how much demand there is for a good 8086 disassembler,
    for example. (Note that the DOS DEBUG command has one.)

    -- glen


  5. Re: Intel 8086 opcodes

    Since nobody answered my question, I had the idea to have a look to
    Wikipedia.

    Somewhere there (I have been unable to refind it, to note the
    reference), I finally found the following:

    '''Added with [[80186]]/[[80188]]'''

    BOUND, ENTER, INS, LEAVE, OUTS, POPA, PUSHA

    '''Added with [[80286]]'''

    ARPL, CLTS, LAR, LGDT, LIDT, LLDT, LMSW,
    [[LOADALL]], LSL, [[Load Task Register|LTR]]
    , SGDT, SIDT, SLDT, SMSW, STR, VERR, VERW

    '''Added with [[80386]]'''

    BSF, BSR, BT, BTC, BTR, BTS, CDQ, CMPSD, CWDE,
    INSD, IRETD, IRETDF, IRETF, JECXZ, LFS, LGS,
    LSS, LODSD, LOOPD, LOOPED, LOOPNED, LOOPNZD,
    LOOPZD, MOVSD, MOVSX, MOVZX, OUTSD, POPAD,
    POPFD, PUSHAD, PUSHD, PUSHFD, SCASD, SETA,
    SETAE, SETB, SETBE, SETC, SETE, SETG, SETGE,
    SETL, SETLE, SETNA, SETNAE, SETNB, SETNBE,
    SETNC, SETNE, SETNG, SETNGE, SETNL, SETNLE,
    SETNO, SETNP, SETNS, SETNZ, SETO, SETP,
    SETPE, SETPO, SETS, SETZ, SHLD, SHRD, STOSD

    So, there seems to have been a big jump in the number of opcodes when
    they switched to 32-bit mode.

    Now that I have an idea of what to search for, I will

    1) rewrite my LIST8086
    2) write a LIST186
    3) write a LIST286
    4) check all the opcodes of ASM-86
    5) add the 186 instructions
    6) add the 286 instructions

    This programme should keep me working for some time.

    (I also need to disassemble SID-86.)

    Only then will I decide if I update the tables to generate 80386
    opcodes. At least, I know from the outset that it is possible. Just a
    question of time and money (as usual).

    Yours Sincerely,
    Mr Emmanuel Roche



+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4