Welcome, Guest. Please login or register.

Author Topic: Gold 2.7 release for the Vampire accelerators  (Read 45171 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« on: March 05, 2018, 07:47:32 AM »
FEmu -
Quote
development has stopped.
That's very unfortunate. So there will be no further versions of it? At least for the other Amiga's it's still needed and wanted (030/040 without FPU).
Will the Source code be released as educational piece or under a open source license so that anyone can continue with it.

Is there anyone know something or has contact to Jari?
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #1 on: March 05, 2018, 11:07:01 AM »
Quote from: guibrush;836913
For example, the Maparium bug was found and I can tell you that this is already corrected, as you can see on this video :
https://www.youtube.com/watch?v=kefOi07_ons

Uhhh... I didn't know that Video, only read that it should be solved. :)

Yes looks very nice, also the precision seems to be not a big issue, but this I would like to test myself. Hard to see on a video.

hmm seems he did not find the Track Property window but it looked like he searched for it, ok "Edit" is a stupid name there. interesting :) Thanks for sharing.

But the Video reminds me, I really should release the new Version with keep-alive support for the network, it makes the map download 10x faster 40kb/s (in the Video) is really slow, on MOS/AROS I reach now >1 MB/s, on Classic 100-400 kb/s should be possible.
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #2 on: March 05, 2018, 01:50:46 PM »
Quote from: Gulliver;836923
I hope you get some compensation for your work.

I would guess they get the same compensation as I get for my FreePascal work (or any other OpenSource coder): Fun (to work on it) and satisfaction that you create something what other find useful and you didn't waste your time but produce something remarkable.

(I have the admit the latter is not very strong for me... with the low FreePascal user count on Amiga systems... but still :))
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #3 on: March 06, 2018, 07:39:17 AM »
Quote from: nyteschayde;836954
Code: [Select]
switch(yourComplaint) {
  case BS_ABOUT_EMULATION:
    goLearnAboutWhatAFPGAIs();
    break;
  case IT_DOESNT_SUPPORT_MY_SETUP:
    waitForOneThatDoesAndBeThankfulInTheMeanTime();
    break;
  case I_CANT_FIND_ONE_TO_BUY:
    learnPatienceOrPayInGoldOnEbay();
    break;
  default:
    if (youDontHaveAnythingNiceToSay) {
      keepYourThoughtsAndOpinionsToYourself();
    }
    else {
      bePatientAndReadTheForums();
    }
}
:huh:
As a developer, I really feel unwell to see something like this...  so there is no room for legit complains? no Bug reports, no feedback at  all...

Every "real" developer is very happy about error/bug  reports, especially when the user searched for a simple reproduction way  and it is  reproducible. At least me, but maybe I'm from yesterday, today you are only allowed to cheer!

Just my 2 cent.
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #4 on: March 07, 2018, 07:34:15 AM »
Quote
So please test software make us aware of bugs, it helps refining the FPU.
Currently I stopped to test stuff on Vampire because of two reasons

  • It's too annoying to work with it, I have such models need some soldering done and well... I'm a software developer, do I have to say more :lol:
  • The Round() bug you found and solved already, as I heard, but I'm not sure if you solved the other "Bug/precise Issue" as well. At least I got no information about. I would only run into the same issue again and again until a new Version is released.
-- Troll mode on
I always thought C is such an efficient language in length of code, but this switch statement looks much longer and complicated than the Pascal variant of it :laugh1:
Code: [Select]
case yourComplaint of
  I_FOUND_A_BUG:              pleaseReportToDevsAndThanksForTheSupport();
  BS_ABOUT_EMULATION:         goLearnAboutWhatAFPGAIs();
  IT_DOESNT_SUPPORT_MY_SETUP: waitForOneThatDoesAndBeThankfulInTheMeanTime();
  I_CANT_FIND_ONE_TO_BUY:     learnPatienceOrPayInGoldOnEbay();
  else
    if youDontHaveAnythingNiceToSay then
      keepYourThoughtsAndOpinionsToYourself()
    else
      bePatientAndReadTheForums();
end;
-- Troll mode off
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #5 on: March 07, 2018, 11:12:20 AM »
@karlos:

Difficult to answer that (for me) I didn't tested it in detail.

Disclaimer: can be completely wrong what I write here, just some very
basic tests on the surface where done! Don't slaughter me if it is completely BS.

https://blog.alb42.de/2018/03/03/vampire-2-7-fpu-part-2/
just this test as you see the
b := b * 1.0000000001;

Needs 11 significant decimals precision

Single has 6-9 significant decimals
Double had 15-17 significant decimals

Vampire (at the current released Version 2.7) does not see this
1 at the 11. position.
That means it has less than 11 significant decimals.
I remember I tried with 9 and it somehow worked (with large
error but that is to be expected at the edge of precision)

So it looks like it uses like single 23 bits for the significant
but it's not Single/32 bit because the numbers can still go up to 10^308
That means the exponent is still 11 bits long as you would expect
for a Double/64 bit.
So it's something new ;-) the VampireDouble with 23 bit significant 11 bit exponent (and a sign bit)
35 bit (but of course in memory the length of 64 bit)

I hope that make some sense.

It could be (and this is what I hope :-P) that this was a bug and solved with the Round() Bug they already solved.
Therefore I'm very careful to claim that all as a fact and continue to investigate when the new fixed version is out.

But the exact information only Gunnar can give you I guess.

Quote
My understanding is that its "not quite 64 bit IEEE" due to some current limitations imposed by gate counts.        
Sure, that's the reason, but my preferred solution would be to make the Single/32 bit calculations in the FPGA and double/extended trap like before to FEmu. or something like this. But maybe they tried but didn't worked as expected.
« Last Edit: March 07, 2018, 11:16:59 AM by ALB42 »
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #6 on: March 07, 2018, 09:24:54 PM »
Quote from: wawrzon;837066
@thor and fpu experts

by the way allow me a quick question ot, as accidentaly a piece of code im working on touches the subject of precision. what do you think should i define or undefine DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS for m68k (with fpu assumably) in this respect?

Code: [Select]
// Double operations detection based on target architecture.
// Linux uses a 80bit wide floating point stack on x86. This induces double
// rounding, which in turn leads to wrong results.

because 68881/68882 68040/68060 will also do so (use 80 bit like x86/x87) I would say for m68k this define should not be set, did you check what kind of code is switched with that define?
 

Offline ALB42

Re: Gold 2.7 release for the Vampire accelerators
« Reply #7 on: March 07, 2018, 10:17:46 PM »
Quote from: Thomas Richter;837071
I probably do not understand the question to full extend. However, *if* you configure a native 68K FPU to double precision (the FPCR allows that), then it works fully in accordance with the IEEE double precision rules, including rounding. If you leave it at 80bits precision, then some results may be more precise (and by that different) from what a fully compliant double precision FPU would get.

yes and no, because m68k FPUs always calculate everything in extended precision see also:

http://www.intel-assembler.it/portale/5/motorola-fpu-programming/68881-68882-68040-command-reference.asp

Quote
2.2.1.1  Floating point data registers

  The data registers always contain an 80 bit wide extended precision
  floating point number.  Before any floating point data is used in
  calculation, it is converted to extended-precision.
  For example, the instruction   FMOVE.L #10,FP3  converts the
  longword #10 to extended precision before transferring it to register
  FP3.  All calculations with the FPU uses the internal registers
  as either source or destination, or both.

Thats the reason it make no big difference on m68k if you calculate
in single or double (only more memory needed)
This difference can lead to different results at the edge of precision and if you make heavy calculations also a inside the save precision area.
You can see that in the link I posted before. The linux x64 and m68k vary from each other at the edge of precision, even both should get the same result (x64 always do 64 bit calculation with SSE2/3, m68k always do 80 bit) and I guess thats what this define is all about.