Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

PCI phased out? (Announce)

posted by marcov, 18.02.2011, 09:30

> > > that was the point, you can't replace something when
> > > it's heavily undocumented (though Win16 is worse here).
> >
> > .. afaik the DV/X function calls are in Ralph Brown. (IIRC 2F calls)
>
> Knowing the interface is (intentionally) not the same as knowing the
> implementation. I assume you understand this. ;-) ;-)
Then how did we get Wine or FreeDOS?

> > Slower since less pipelinable than non stalling reg operations. And the
> > more regs, the more unnecessary stalls can be avoid.
>
> Slower? Barely (if at all). Push/pop has been fast, esp. since Pentium (two
> in one clock). How many free registers is enough, 16? 256? 512? 1024?
16 is a nice number.

> > Double code generation unnecessary checks everywhere. And for what?
>
> You only have to "check" (CPUID) once at startup and use function pointers
> loaded appropriately, then you don't have to worry about anything.
Except double code/maintenance, disabling of inlining in many places etc.

> And like I said, the obvious advantages from using SSE2 are few and far in
> between, so the code duplication is very very little (way less than 1 kb
> for paq8o8z for literally a 2x speedup).
paq is not a good example since the code is probably manually crafted for speed and has intense tight loops. I don't consider it general purpose app code.

> > FPC can, GCC, MSVC can, Intel can afaik. Borland has not 64-bit
> compilers.
>
> I don't think so. Most of them pale heavily (from what I've heard)
> in comparison to Intel (no surprise). At least GCC, in my very limited
> testing, wasn't even 5% effective.
Vectoring or simple FPU usage according to ABI is a different thing. I have to admit that I don't know all ins and outs of that either. I doubt SSE2 FP fully lives up to the IEEE standards

> > I've heard it repeated several times, not available in long mode. Afaik
> it
> > is in the AMD manuals.
>
> Unless you really want to dig in or ask these guys themselves, I suggest
> you keep an open mind. Not that I ever expect anybody to fix it or do
> anything about it, but I guess it's possible.

I think it is possible too, but the likeliness that it is, is too low to actually react to.

More importantly, a year or two back (when the first 64-bit Windows versions entered here), I gave up the last 16-bit binary. QEdit. Though I hadn't used it that much, usually using cygwin based JOE. It was more a motivation to dig a bit deeping into joe.

So now I only have BP7 and TS that I occasionally start. (as in less than one year). For that, an old win9x laptop serves me right. Still have to test these with wine, though in the past the integrated debuggers often made emulation hard..

> In general, I would trust a
> kernel hacker more than an average joe. (And BTW, I read on Wikipedia
> yesterday that WINE 64-bit does run Win16 apps. It didn't say anything
> about slow emulation. But I haven't tested. Most, if not all, Win 3.x apps
> are indeed pmode-friendly.)
Probably win32s apps.

> Like I said, I only know that DOSEMU x86-64 has to full emulate 16-bit real
> mode stuff, from personal testing. It's very slow for that, annoyingly slow
> (so 64-bit's own alleged speedups overall doesn't cover that wound).
Well. I guess it is enough to start up BP and browse around :)

> However, DJGPP (32-bit) stuff is native speed (e.g. Quake). I never tested
> any 16-bit pmode stuff since that's relatively rare these days (oddly). I
> should test again one day soon just for curiosity (HXDEV16 ftw!).
Hmm. Some code through a JIT, some not? Or do you use some specific version of some extender? Since DOSEMU needs to process the 16-bit extender startupcode too, even if the bulk is 32-bit ?

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 405 users online (0 registered, 405 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum