I would think

Yes, would be a good idea to think before posting something, then finding
some facts about it, then querying more information, then finding out how
the dynamic core handles the fpu, then continuing with the thinking, then
re-reading the thread, then trying to understand what's written there, what
the discussion was about.

Would have been a good idea, yes.

wd wrote:

You see what I mean?

Yeah, feel free to do that. I (and Qbix+Harekiet+etc.) neither have the time to,
nor do i get money for that.

Please stop the "we are a bunch of volunteers" attitude for a moment. You know very well that I have been contributing to dosbox for years (although it is extremely hard to get patches accepted, even if they are written as unobtrusive as they can get), I don't get money for it, and I don't have time either.

BTW, I actually did give you a LIMITATIONS file in my last post. It contains all I was able to recall off the top of my mind, and it might be a little inaccurate due to me being no CPU emulation guru. But it took me less than 5 minutes to type. You can't tell me you don't have 5 minutes time for a little bit of sustainable development. Typing one single line in case you stumble over an intentional limitation will take 30 seconds. And you get a document that helps introducing new developers and explaining to users likewise.

wd wrote:

No, it uses the math lib, but a bit more decoding in the recompiling stage than the normal core would do (see dyn_fpu.h). The so […]
Show full quote

Would dynrec on x86_64 use 80bit?

No, it uses the math lib, but a bit more decoding in the recompiling stage
than the normal core would do (see dyn_fpu.h).
The softfloat lib would be something to use for full precision, but think most stuff that uses it ignores the exceptions as well.

Well, should I ever run a game that suffers from this, I'd try to follow that road. Out of curiosity, what do you think would be easier: writing a separate core (based on dynrec or normal), or implement some sort of run-time selectable FPU core?

Lots of respect wd, really, but I did read the entire thread and understand all of the issues and every part except the core stuff. I meant that in the IA-32 package that's made available you could have a pre-compiled executable that uses native FP instead of emulation; I don't think it would require too much indirection, I "would think" that you should be able to just rewrite the FP function(s) and not be dynamic. I may be way off on that.
I was trying to be helpful.
I appreciate DOSBox.
I don't appreciate being accused of not thinking.

I don't get money for it, and I don't have time either.

As much as you're free to do what you like, as much i'd prefer to do
that as well without other people telling me what to do, ok? Nice.

that helps introducing new developers

If they want to change something, they can read the code.
Btw. i've volunteered some years ago for writing extensive source
and regular documentation, but it would not have been included.

writing a separate core (based on dynrec or normal),
or implement some sort of run-time selectable FPU core?

In any case the first thing should be fiddling with the normal core,
as it is available everywhere. Easiest thing is to make it compiletime
changeable, the current layout does not allow for runtime switching
of the fpu/implementing it that way.
If sticking to the style of the fpu_instructions.h it will work for the
recompiling core as well.

I was under the impression IA-64 had native IA-32 emulation, or simulation, or something; am I wrong?

I don't know what/if something changed, probably the addressing/memory
access functionality. Either way the dynrec core is not prepared for
directly using the host fpu, only the x86-only dynamic core.

I may be way off on that.

Right. Way off. You can't "just use the host stuff".

I didn't say "just use the host stuff" and I was trying to be nice, but... well, I guess this is the famous forum 'tude I've heard so much about.
At any rate, unless every single thing in DOSBox is emulated, you could have the FP instructions be real (and everything may be emulated, I don't know, but at least I'm willing to concede that I may be wrong).
I also would suggest a chill pill.

`Moe` wrote:

- protected mode core can't handle recursive initialization. Affected games: Frontier: First Encounters (use jjffe instead) [rationale: not needed, since the only affected game has a source port]

Just to add, it appears that FFE works in latest DOSBox CVS (with default settings 😜 ).

you could have the FP instructions be real

No you can't.

I said I could be wrong.
again, chill pill, wd
not insulting your intelligence or demeaning your efforts

Does that mean every single thing in DOSBox is emulated? I just want to know.

I said I could be wrong.

Dunno why you're "contributing" to this thread then.

Does that mean every single thing in DOSBox is emulated?

Not every single thing. Some stuff is left out, much (bios code) is done in
higher levels than usual emulators would do.
As the cpu is the heaviest part, Harekiet added a core that dynamically
recompiles code (core=dynamic on x86). This means an x86 to x86 translation.
Later the fpu was integrated into the recompiler to allow usage of the host
fpu as much as possible (use a defined fpu state, read operators from
emulated memory into host fpu regs, work with them as long as possible,
saving back the state when the block chaining ends). Very fast (by no
means the fastest) and very compatible (80bit precision) thing.

a limitations file might be good idea,
but I'm afraid some people will slap us around with it if something doesn't work (claiming/thinking that it is caused by the limitations listed).

Qbix wrote:

a limitations file might be good idea,
but I'm afraid some people will slap us around with it if something doesn't work (claiming/thinking that it is caused by the limitations listed).

Well, then stick a big disclaimer at the beginning. Yes, people will continue asking stupid questions, even if documented in the limitations file, but it would be of a huge benefit to the more serious db users.

JAL

I had two suggestions, a comment, and a question. Unless I'm helping someone, I never assume I'm contributing anything.

wd wrote:

I don't get money for it, and I don't have time either.

As much as you're free to do what you like, as much i'd prefer to do
that as well without other people telling me what to do, ok? Nice.

Sorry that it looks like I'm trying to do that. It's just that you dismiss some ideas so quickly that I feel compelled to take a stance for them. All I want to do is convince you that the idea is perfectly realistic, contrary to your initial claims. What you actually make of it is, of course, your personal matter.

I was under the impression IA-64 had native IA-32 emulation, or simulation, or something; am I wrong?

Minor nitpick on Mr. Vagueness: IA-64 is not x86_64, and is not widely known. While having some user base in commercial server applications, there is next to no desktop/home use of the architecture.

The x86-emulation of x86_64 works on a process level: You can run an unmodified 32bit-binary because of it. But since the instructions have a new meaning, just using the 32-bit dynamic core in a 64bit application is not possible.

wd is not always very ... diplomatic. But I love him anyway.

`Moe` wrote:

Minor nitpick on Mr. Vagueness: IA-64 is not x86_64, and is not widely known. While having some user base in commercial server applications, there is next to no desktop/home use of the architecture.

I didn't know, I don't know if I've heard that before; I thought they were synonyms, like IA-32 and 386-base or Pentium-base. I figured IA-64 would be Intel's 64-bit PC architecture. I found out about most of this from a Wikipedia article. I'll look up x86_64.
As I said, no disrespect towards wd, but yeah, I dislike the lack of "diplomacy".
I think if someone is acting like a noob, you should just tell them, maybe point them in the right direction, and get on with your life, rather than trying to pwn them at something you're obviously better at.
oh, and I didn't go to on-line fake basic training to be called "Mister"😉

you might want to read the stuff in my signature.
Wd is quite nice compared to the avarage hacker portrayed there.

MiniMax wrote:

wd is not always very ... diplomatic. But I love him anyway.

@DosFreak: Does that mean you like flame-throwing (which I didn't mean to do, if I was doing it, BTW)?
nice picture, I saw it elsewhere and didn't get it, I get it now, I used it here.
@Qbix: I read it, changed my sig. because of it
it's not easy to get me to change things I made that I like
this is getting off topic, but then the original question has been answered
since then it's just been wd getting on `Moe` and I and stuff related to that