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, 17.02.2011, 19:44

> > Huh, how does it replace DV/X? Does it have job control or so?
>
> No (see "mostly"?),

The core feature not being supported is not "mostly". and..

> 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)

> > In my experience it about evens out on non-Windows. The larger
> datasegment
> > size on one hand, and the large number of registers and raised minimal
> > instruction level (and the systematic use of both in every library)
> about
> > cancel eachother.
>
> You don't need extra registers (use push/pop).

Slower since less pipelinable than non stalling reg operations. And the more regs, the more unnecessary stalls can be avoid.

> You don't need to assume
> SSE2 (use CPUID),

Double code generation unnecessary checks everywhere. And for what?

> which most compilers can't target anyways.

FPC can, GCC, MSVC can, Intel can afaik. Borland has not 64-bit compilers.

On 64-bit SSE2 is mandatory for FP, as per ABI. Original ABI's even deprecated FPU (and e.g. Windows XP/64 doesn't support it)

> Besides, there
> are ten bazillion extensions since SSE2 was a standard on all PCs (P4 -
> 2000, AMD64 - 2003): SSE3, SSSE3, SSE4.[12], AVX, etc. (Even new cpus don't
> have all these, not even close!)


Sure but except for SSE3 and AVX these are not that interesting. And as said it is the base level that is interesting, not the options. (SSE3 because it lowers SSE2 alignment requirements, and AVX, when it is supported (which it isn't) will double again). Probably in say 7 years we'll repeat this discussion for AVX

> Yes, in very rare cases, SSE2 can speed up
> an app significantly, but you don't need 64-bit for that.
Was not the point. The AES case was just an extreme example to offset your extreme answer.

My point was that while only a few percent, increased CPU requirement (and not just the theoretic possibility, but the fact that it is ACTUALLY used in all 64-bit software that you have, together with the few percent of the extra regs compensates the slowdown due to increased datasize in realworld code. Dr Dobbs has an interesting article about it.

> > > Why did they not implement V86 under long mode?
> >
> > One emulation only. 64-bit has 32-bit. 32-bit has 16-bit.
>
> 16-bit covers real mode (8086 - MS-DOS) and pmode (286 - OS/2 1.x), two
> entirely different things (though they both use segmentation).
I'm talking about V86 mode.

> I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not
> entirely sure if the cpu (long mode) itself or just the 64-bit OSes (Win64,
> Linux64) refuse to support one or both of those.
I've heard it repeated several times, not available in long mode. Afaik it is in the AMD manuals.

> > That next to nobody needs it is probably true too.
>
> The cpu and OS vendors are heavily tied together and make decisions
> (sometimes irrational) based upon one another (silly examples redacted).
And some people believe every conspirancy theory :-)

> > And more importantly, if they add it now for a few 16-bit vigilantes,
> they
> > can't get rid of it till 2025. Keep in mind that 80386 was introduced in
> > 1985, and as an arch is only starting to be phased out.
>
> The 286 was still used until early '90s (according to Wikipedia).

Yes. But I'm not going to quibble over a few years. I think the win9x argument being dos is totally bogus though. Despite the few kb of heavily modified dos kernel here or there, users experienced as Windows, not as dos (safe for a few refuseniks)

> > > I don't ever (!) want them to remove 32-bit compatibility.
> >
> > I'm not that afraid about 32-bit EXEs running, but 32-bit OSes are in
> > danger due to the BIOS->EFI change.
>
> All new drivers (sigh), another drawback.
I don't understand this remark

> > Naah. The wrath of the long tail rules there. PE bins will run for quite
> > while within windows. And I guess 32-bit OSes will run for a handful of
> > years minimum too. Anyone who says that he can look forward longer than
> > that must be a multi-millionaire, since he would have bought a gazillion
> > Apple shares early this decennium if he could forsee IT that well.
>
> Of course they can't do it now. But give them five years.

Yup, there is a fair chance that then the situation will become neglected, and legacy bioses might be removed.

> As long as 50% of the people "don't care", they'll probably do it. I mean, > if they
> can't even keep NTVDM barely working on XP (2001-6), what makes you
> think WoW 32-bit will be any different??
Maybe the same will happen. It will be decent long enough to keep apps running a while. Games and other special software will be harder.

But Dos was a hard system to emulate. For the business apps it will be easier.

> > > Yes, modern PCs are crap.
> >
> > Sigh, more nagging and whining. What are you going to about it?
>
> What do you reasonably expect me to do about it?

I don't know. I can't entirely grasp a concept that seems illogical to me.

> Do you really think Win32 or FreeBSD64 is the answer?

No, since they go with mainstream. The point is more that I assume you have a plan if you insolate yourself :)

> Doubt it. And certainly you don't
> expect me to roll my own hardware (though presumably the 386 is patent
> free by now, maybe even 486, I dunno).
I think that is a bridge too far. The numbers have become to low I guess. (and the organisation level of Dos users is too low).

But buying in groups hardware that more or less does work is not too hard. Improve the support of Coreboot for that hardware to make it even better.

Post reply
 

Complete thread:

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