Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #64275 > unrolled thread

emulating 8086 subset.

Back to article view | Back to comp.lang.c

Contents

  emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-27 00:34 -0700
    Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-27 01:18 -0700
    Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-27 01:28 -0700
      Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-28 21:21 -0700
      Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-28 22:50 -0700
        Re: GOLFulating 8086 subset. gensym? luser droog <luser.droog@gmail.com> - 2015-07-01 15:36 -0700
          Re: GOLFulating 8086 subset. gensym? luser droog <luser.droog@gmail.com> - 2015-07-01 16:02 -0700
            Re: GOLFulating 8086 subset. gensym? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 16:11 -0700
              Re: GOLFulating 8086 subset. gensym? luser droog <luser.droog@gmail.com> - 2015-07-01 16:52 -0700
                Re: GOLFulating 8086 subset. gensym? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 16:56 -0700
                  Re: GOLFulating 8086 subset. gensym? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 22:12 -0700
    Re: emulating 8086 subset. Ian Collins <ian-news@hotmail.com> - 2015-06-27 21:38 +1200
      Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-06-27 02:51 -0700
        Re: emulating 8086 subset. Richard Heathfield <rjh@cpax.org.uk> - 2015-06-27 13:02 +0100
          Re: emulating 8086 subset. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 14:25 +0100
          Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-07-11 00:51 -0700
            Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 01:54 -0700
              Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-07-11 01:58 -0700
              Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 01:59 -0700
                Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-07-11 02:13 -0700
                  Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 02:34 -0700
                    Re: emulating 8086 subset. Bartc <bc@freeuk.com> - 2015-07-11 10:50 +0100
                      Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 02:58 -0700
                    Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 02:52 -0700
            Re: emulating 8086 subset. Bartc <bc@freeuk.com> - 2015-07-11 10:38 +0100
              Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-07-11 03:16 -0700
                Re: emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-11 03:19 -0700
    emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 03:07 -0700
      emulating 8086 subset. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 03:58 -0700
    Re: emulating 8086 subset. luser droog <luser.droog@gmail.com> - 2015-07-10 10:51 -0700
    Re: emulating 8086 subset. JohnF <john@please.see.sig.for.email.com> - 2015-07-11 10:07 +0000

Page 2 of 2 — ← Prev page 1 [2]

#65240

I believe the 186 was an 86 with hard-wired
external interrupt vectors.

x86 is inherently little endian. What is your
strategy for introducing big endian?

You should see my Li386-x40 project, a 40-bit
80386 with limited ARM support and custom
ISA and architectural extensions:

   https://github.com/RickCHodgin/libsf/tree/master/li386/li386-documentation/images

   http://www.libsf.org/li386/indexmain.html 

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65242

On 11/07/2015 10:34, Rick C. Hodgin wrote:
> I believe the 186 was an 86 with hard-wired
> external interrupt vectors.

80186 and 80188 were very different from the rest of the x86 series.

They had integrated peripherals such as DMA, interrupt controllers and 
timers. This also meant they were incompatible with IBM PCs which used 
discrete components, so they didn't catch on.

(I used the 80188 as the basis of a very early laptop project - in 1984! 
Very nice processor, I wrote a gorgeous assembler for it as it had many 
new features. But the compatibility issue was a problem.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#65245

Bartc wrote:
> This also meant they were incompatible with
> IBM PCs which used discrete components, so
> they didn't catch on.

Seems they learned their lesson there with future CPUs. :-)
Even Itanium had x86 emulation support in hardware.

I was very surprised Intel sold XScale, however.
Seemed a wrong move.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65244

I stand corrected:

   https://en.wikipedia.org/wiki/Intel_80186

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65241

On 11/07/2015 08:51, luser droog wrote:
> On Saturday, June 27, 2015 at 7:02:37 AM UTC-5, somebody wrote:
>>
>> *Lose the macros*.
>
> non-wrapped at:
> https://gist.github.com/luser-dr00g/aef0342cb4a63d682c13

It hasn't really helped! Now there are the pointless typedefs. And (I 
haven't followed the thread) presumably the original macros have been 
expanded, but resulting in a large, unformatted lines or blocks of code.

Isn't there a tool that can take such code and format it properly? (But 
somehow I doubt that will help.)

It's not clear what the aims are here: to make something as fast as 
possible or as compact as possible. It's certainly not readability!

> typedef intptr_t I; typedef uintptr_t U;

Nobody uses I or U. Enough people i32, u32 etc that at least it will not 
look totally alien.

> typedef signed char C; typedef unsigned char UC;

And here 'byte' is better. At least it looks like a type!

> UC*al;UC*ah;UC*cl;UC*ch;UC*dl;UC*dh;UC*bl;UC*bh;US*ax;US*cx;US*dx;US*bx;US*sp;US*bp;US*si;US*di;US*ip;US*fl;US*cs;US*ds;US*ss;US*es;V init(){I i=0;al=(UC*)(reg+i++);ah=(UC*)(reg+i++);cl=(UC*)(reg+i++);ch=(UC*)(reg+i++);dl=(UC*)(reg+i++);dh=(UC*)(reg+i++);bl=(UC*)(reg+i++);bh=(UC*)(reg+i++);i=0;ax=(US*)(reg+i);i+=2;cx=(US*)(reg+i);i+=2;dx=(US*)(reg+i);i+=2;bx=(US*)(reg+i);i+=2;sp=(US*)(reg+i);i+=2;bp=(US*)(reg+i);i+=2;si=(US*)(reg+i);i+=2;di=(US*)(reg+i);i+=2;ip=(US*)(reg+i);i+=2;fl=(US*)(reg+i);i+=2;cs=(US*)(reg+i);i+=2;ds=(US*)(reg+i);i+=2;ss=(US*)(reg+i);i+=2;es=(US*)(reg+i);i+=2;}

Let me guess, a macro expansion? How would you write it if you had to do 
by hand?

My point is that as written, it's not really human readable. I'm not 
sure it even counts calling it C, even if it makes legitimate use of the 
macro preprocessor.

 >ch=(UC*)(reg+i++);dl=(UC*)(reg+i++);dh=(UC*)(reg+i++);bl=(UC*)
 >(reg+i++);bh=(UC*)(reg+i++);i=0;ax=(US*)(reg+i);i+=2;cx=(US*)(reg+i);
 >i+=2;dx=(US*)(reg+i);i+=2;bx=(US*)(reg+i);i+=2;sp=(US*)(reg+i);i+=2;bp=
 >(US*)(reg+i);i+=2;si=(US*)(reg+i);i+=2;di=(US*)(reg+i);i+=2;ip=
 >....

This looks like it's crying out for these register variables to be 
implemented as arrays (which is how it works on the actual chip; 
registers are indexed by 0 to 7). With registers such as AX/AL/AH 
implemented as unions... But then as I said I don't know what the aims are.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#65248

On Saturday, July 11, 2015 at 4:38:43 AM UTC-5, Bart wrote:
> On 11/07/2015 08:51, luser droog wrote:
> > On Saturday, June 27, 2015 at 7:02:37 AM UTC-5, somebody wrote:
> >>
> >> *Lose the macros*.
> >
> > non-wrapped at:
> > https://gist.github.com/luser-dr00g/aef0342cb4a63d682c13
> 
> It hasn't really helped! Now there are the pointless typedefs. And (I 
> haven't followed the thread) presumably the original macros have been 
> expanded, but resulting in a large, unformatted lines or blocks of code.
> 

Yes. The plan was to make the macros seem more reasonable.
Not sure of the success of that endeavor.

> Isn't there a tool that can take such code and format it properly? (But 
> somehow I doubt that will help.)
> 

Yes. I've passed it through `indent`.
https://gist.github.com/luser-dr00g/e907e5beb79fb1edafda


> It's not clear what the aims are here: to make something as fast as 
> possible or as compact as possible. It's certainly not readability!
> 
> > typedef intptr_t I; typedef uintptr_t U;
> 
> Nobody uses I or U. Enough people i32, u32 etc that at least it will not 
> look totally alien.
> 
> > typedef signed char C; typedef unsigned char UC;
> 
> And here 'byte' is better. At least it looks like a type!
> 
> > UC*al;UC*ah;UC*cl;UC*ch;UC*dl;UC*dh;UC*bl;UC*bh;US*ax;US*cx;US*dx;US*bx;US*sp;US*bp;US*si;US*di;US*ip;US*fl;US*cs;US*ds;US*ss;US*es;V init(){I i=0;al=(UC*)(reg+i++);ah=(UC*)(reg+i++);cl=(UC*)(reg+i++);ch=(UC*)(reg+i++);dl=(UC*)(reg+i++);dh=(UC*)(reg+i++);bl=(UC*)(reg+i++);bh=(UC*)(reg+i++);i=0;ax=(US*)(reg+i);i+=2;cx=(US*)(reg+i);i+=2;dx=(US*)(reg+i);i+=2;bx=(US*)(reg+i);i+=2;sp=(US*)(reg+i);i+=2;bp=(US*)(reg+i);i+=2;si=(US*)(reg+i);i+=2;di=(US*)(reg+i);i+=2;ip=(US*)(reg+i);i+=2;fl=(US*)(reg+i);i+=2;cs=(US*)(reg+i);i+=2;ds=(US*)(reg+i);i+=2;ss=(US*)(reg+i);i+=2;es=(US*)(reg+i);i+=2;}
> 
> Let me guess, a macro expansion? How would you write it if you had to do 
> by hand?
> 
> My point is that as written, it's not really human readable. I'm not 
> sure it even counts calling it C, even if it makes legitimate use of the 
> macro preprocessor.
> 
>  >ch=(UC*)(reg+i++);dl=(UC*)(reg+i++);dh=(UC*)(reg+i++);bl=(UC*)
>  >(reg+i++);bh=(UC*)(reg+i++);i=0;ax=(US*)(reg+i);i+=2;cx=(US*)(reg+i);
>  >i+=2;dx=(US*)(reg+i);i+=2;bx=(US*)(reg+i);i+=2;sp=(US*)(reg+i);i+=2;bp=
>  >(US*)(reg+i);i+=2;si=(US*)(reg+i);i+=2;di=(US*)(reg+i);i+=2;ip=
>  >....
> 
> This looks like it's crying out for these register variables to be 
> implemented as arrays (which is how it works on the actual chip; 
> registers are indexed by 0 to 7). With registers such as AX/AL/AH 
> implemented as unions... But then as I said I don't know what the aims are.
> 

They're implemented as overlaying pointers so the guts of the opcode
functions could treat a register or memory identically. Unfortunately,
this destroys my attempt to lay the registers out "native-endian" for
speed (appropriate for registers).

[toc] | [prev] | [next] | [standalone]

#65249

On Saturday, July 11, 2015 at 6:16:42 AM UTC-4, luser droog wrote:
> [snip]

I would like to suggest you use proper human readable names.  While
making some of your code longer, it will aid in maintenance in the
long term and is well worth the "extra cost" of the additional
typing.  It also aids in editors which have auto-completion, as you
begin typing something and it suggests those which are close based
on context.

In a few years when you come back to this project, having the long
names will serve your aging mind/eyes well. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#64281

This is currently setup for i686, but you could
modify it for 8086 only. I modified it one time
so I could debug my floppy boot loader:

    https://github.com/RickCHodgin/libsf/tree/master/source/unsorted/DebiX86Disassembler

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#64283

Here's the original assembly version that C code
is based upon:

    https://github.com/RickCHodgin/libsf-full/tree/master/_exodus/source/x86

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65153

On Saturday, June 27, 2015 at 2:34:56 AM UTC-5, luser droog wrote:
> Brain going numb trying to overdesign this apl jiterpreter,
> and reading this tutorial on category theory for programmers.
> So I tried a little fun project to rewrite my postscript
> 8086 emulator to (superterse) C.

Posted!
http://codegolf.stackexchange.com/questions/4732/emulate-an-intel-8086-cpu/52902#52902

It mostly works. still some bugs I need to track down.
Fortunately, I have the other working version I can test
against by running both step by step in parallel (by 
which I mean two xterm windows and repeated sequences
of ALT-TAB ENTER).

[toc] | [prev] | [next] | [standalone]

#65247

luser droog <luser.droog@gmail.com> wrote:
> Brain going numb trying to overdesign this apl jiterpreter,
> and reading this tutorial on category theory for programmers.
<snip>

No comment on your <snip>'ed ps interpreter, but of the several
books I've read about it, and depending on your background and
purpose,
  https://mitpress.mit.edu/books/basic-category-theory-computer-scientists
is quite a competent and thorough-yet-concise introduction.
Though that's the one I'd recommend, I'm not familiar with books
written after ~y2k, so similar/better/whatever ones may well exist.

Google doesn't seem to be coughing up a free pdf of it, but if
you're investing enough time to read it, then the $30 bucks is worth it
to invest your time as productively as possible. There does seem
to be a page of reader reviews (beware line-wrapped url),
  http://www.goodreads.com/book/show/1810837.Basic_Category_Theory_for_Computer_Scientists
Some of the pure programmer types seem to feel they don't quite
have the prerequisites. I have an ms in physics, and couldn't
just breeze through it, but it wasn't like a 50mph headwind in
my face, either. Pitched just about perfect for me, but obviously ymmv.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web