Gold 2.7 release for the Vampire accelerators

[ALB42]

@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?

[UberFreak]

This discussion is somewhat entertaining and incredibly pointless at the same time.

Going by this logic, is the Amiga 1000 emulating (sorry, "interpreting") Lorraine, using ASICs ?

PS: sorry for OT

[LoadWB]

This discussion is somewhat entertaining and incredibly pointless at the same time.

Going by this logic, is the Amiga 1000 emulating (sorry, "interpreting") Lorraine, using ASICs ?

PS: sorry for OT

I don't think anyone around here cares anymore about threads getting all shytted up with tangential arguments and shyt-slinging.

[wawrzon]

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,

i suspected so.

did you check what kind of code is switched with that define?

its a huge project and i fear it uses a lot of fpu. just want to get it compile for 68k first;)

[guest11527]

@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?

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.

This is why it is so important to have the FPU properly configured for the math libraries. Or actually, the math libraries do the proper configuration, but only for the task that opened the library.

[wawrzon]

@alb42&thor
thx for the input. ill have to keep it in mind as potential source of trouble and leave for further investigation later. im past this point for now so lets return to the topic.

[ALB42]

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

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.

[psxphill]

You clearly have no clue. A CPU built from discrete gates IS a CPU and thus not an emulation. Hence, it is _implemented_ using gates, not emulated.

If I make a real CPU which emulates a 6502, it's emulation. It's not a real 6502.

You are emulating an idiot. You're still a real human being.

Does CR-RW emulate CD-ROM? That's FPGA is, a CD-RW. And 080 is a 68k CPU.

CD-RW and CD-ROM are actually quite different in their properties & have no logic. It's quite a crazy analogy, a real straw man. But in keeping with media analogies, Alot of Compact flash cards can emulate IDE hard drives. SATA controllers can emulate IDE controllers.

It's no different to sound blaster emulation or epson printer emulation back in the 1980's. Those were also real hardware that weren't running a software emulation.

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.

I work on a big software project and we've recently ditched x87 support on our 32 bit builds because the precision was different to the sse used in the x64 builds. We lost support for a few cpus that were still technically possible to run, but the results are now the same.

[grond]

If I make a real CPU which emulates a 6502, it's emulation. It's not a real 6502.

A "real CPU that emulates a 6502" would be e.g. a i7 running a VIC20 emulator. If the "real CPU" executes 6502 code natively, then you  _implemented_ a 6502.

[psxphill]

A "real CPU that emulates a 6502" would be e.g. a i7 running a VIC20 emulator. If the "real CPU" executes 6502 code natively, then you  _implemented_ a 6502.

If you make something capable of running 6502 programmes using TTL then it most certainly is not a 6502.

If you take the 6502 decap and use the die shots to make masks & run a chip fab in your kitchen then you can claim to have made a 6502. Anything else and it's just pretending to be a 6502, AKA emulating.

A hardware emulation is still an emulation.

[NorthWay]

If you make something capable of running 6502 programmes using TTL then it most certainly is not a 6502.

"If you make Lorraine capable of running Amiga programmes using TTL then it most certainly is not a Amiga"

[Niding]

One of the first topics I saw on forums when I returned to the Amiga community was "its emulation!" "No its not".

Rinse repeat for pages and threads.

Its quite mindboggeling that people in their 30s-40s++ can keep THIS up for decades.

I dont do this often, but to quote Trump "Its SAD! Believe me!".

[grond]

If you make something capable of running 6502 programmes using TTL then it most certainly is not a 6502.

If you take the 6502 decap and use the die shots to make masks & run a chip fab in your kitchen then you can claim to have made a 6502. Anything else and it's just pretending to be a 6502, AKA emulating.

Aha. So if I built my 6502 as a silicon chip without looking at the 6502 die and by accident came up with the identical netlist as what you consider a 6502, what would it be? Emulation or the real thing? Seems to be some philosophical straw you are clutching at.

BTW, nobody claims the 68080 was a Motorola 68000, 68010, 68020, 68030, 68040 or 68060, remember? It isn't emulating any of them either, not even when applying the meaning you like to give that word. The 68080 implements the _68k ISA_. And it is implemented in an FPGA.

[IanP]

If you make something capable of running 6502 programmes using TTL then it most certainly is not a 6502.

If you take the 6502 decap and use the die shots to make masks & run a chip fab in your kitchen then you can claim to have made a 6502. Anything else and it's just pretending to be a 6502, AKA emulating.

A hardware emulation is still an emulation.

Which "6502" is the real one that you need to decap to make your own one? The first publicly available one from 1975 with all the bugs, the one from 76 which fixed the ROR bug, the later CMOS version that fixed the 'JMP ($xxFF)' bug amongst other and added additional instructions and addressing modes or one of the dozens if not hundreds of variants that have been designed and manufactured by several companies over the past 40 odd years. By your definition everything but the 1975 die ones are just pretending to be a 6502 AKA emulating one I suppose? :rofl:

[guest11527]

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

Hold on! You miss something here. IEEE floating point has rouding and guard and sticky bits for a reason. The reason is the following: If you first compute with infinite precision (if you could) and then would round to the target precision, the result is the same as if you would first compute with finite precision (plus round, guard and sticky bit) and then would use the three extra bits to round off the result according to the IEEE rounding rules.

Hence, whether the 68882 uses internally 80 bits or 64 bits does not matter. If you switch it to "double precision rounding" with the fpcr, then the result will always be "double correct" as if the computation was performed all the way in double.

So, unlike you claim, there is no difference between a "truncated to 64 bit FPU" and a "80 FPU with 64 bit rounding".

[psxphill]

Aha. So if I built my 6502 as a silicon chip without looking at the 6502 die and by accident came up with the identical netlist as what you consider a 6502, what would it be? Emulation or the real thing? Seems to be some philosophical straw you are clutching at.

You're the one that is trying to break my argument by using stupid philosophical arguments. It's impossible that you will happen to create an identical mask without referencing the original.

Which "6502" is the real one that you need to decap to make your own one?

It depends which behaviour you want, it's often important to get the correct one for your application.

By your definition everything but the 1975 die ones are just pretending to be a 6502 AKA emulating one I suppose? :rofl:

No, that is by your definition. I don't consider someone speaking to be doing an impression of themselves, even though over time you have cells die and new ones grow & are no longer the exact same person with the exact same abilities.

Going back on topic. VHDL is a language, like any other programming language. It allows you to control the gates in an FPGA, like you can control the gates in a CPU. You can implement a 6502 in C running on an x86 or implement a 6520 in verilog running on an fpga. Both are emulating certain behaviours of a 6502.

BTW, nobody claims the 68080 was a Motorola 68000, 68010, 68020, 68030, 68040 or 68060, remember?

https://en.wikipedia.org/wiki/Ship_of_Theseus == strawman, got it?