Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...
   All Posts (biggun)


(1) 2 3 4 ... 9 »


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:

twilen wrote:
That sounds fine, at least in theory.

In theory because there is no compiler or assembler support, "optimization" will unfortunately become something like "Lets do it in Apollo assembly in hexadecimal, we must micro-optimize everything in assembly, we have new instructions, they should be used!!1!" which won't help other builds.


Hello Toni,

I sense in your post some misinformation.
Allow me to clear this up.


Lets first make clear if there is a need to write anything new:

First of all, Apollo 68080 is 100% CPU compatible to existing 68K. This means code compiled for 68000 or 68030 or 68040 or 68060 - will just run fine.
Just faster. So there is generally no need at all to write all new.


Second, you say there is no ASM nor Compiler support.
What you say is not correct.

1) VASM supports, all new APOLLO instructions
2) We have macros allowing to you to use the new instructions in Devpac, ASMOne etc.
3) We have written numberous patches for GNU ASM, which will also allow using the new instructions in GNU environment.
4) C Compiler support is also worked on.

This means the "scenario" that in the future AROS development need be coded in HEX - is simply not correct.


Third, AMMX SIMD does offer the same features and operations as the existing SIMD instructionsets used in POWER and by INTEL, ARM and all the others. This means if a C compiler is generally able to use such SIMD features for INTEL, then enabling this for APOLLO 68K in the future is possible.
We have discussed this with Compiler developer, so this is no problem.

Does this info help you?
All fear gone now?

Posted on: 6/29 0:22
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Gentlemen,

I'm very happy to answer technical questions to Hyperthreading on 68k - but as long people post so much nonsense here,
its not possible to discuss technical details.


Posted on: 6/27 16:16
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:

There you could make clear, that actual vampire-cards do not have a FPU (yet)


Fact:
The Vampire2 were never advertised with FPU.
Igor, Brian, and resellers are very honest here and advertise them with "CPU" and with > 100 MIPS.

Never was Vampire2 advertised with MFLOPS numbers.
Never was Vampire2 advertised with FPU included.

If Igor sells you his car, does I then need to clarify for you that his car does not include his house, nor his board, or his wife?
Cards are sold 100% as they were advertised.


Posted on: 6/27 2:50
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:

cybergorf wrote:
Quote:

Gunnar wrote:
"We produce the APOLLO CORE and the SAGA chipset.
We here do _NOT_ produce the Vampire2."



So what do you care about the new Standalone and the new V1200 card?

You should think about your statements, Gunnar, before you accuse other people.


This discussion does acutally not belong here.
If you have question abotu which FPGA cards available this is not the right place.

But as you seem very confused.

Here is some information for you.

1) Vampire is not the only system using FPGA and APOLLO core.

2) The Vampire1 was designed by Igor.
The Vampire2 was designed by Igor.

The VAMPIRE1 use a very tiny FPGA not able to hold APOLLO CORE.
For the Vampire1 we created a downstripped micro size version of APOLLO CORE which we called Mini-PHOENIX Core.
The mini-Phoenix is APOLLO CORE based but with many features turned off.

The VAMPIRE2 has a bigger FPGA.
For this a "normal" Version of APOLLO CPU Core is shipped with 2 Pipes enabled. (not three pipes!)
Because of FPGA size and time constraints the FPU is not enabled in the current VAMPIRE2 releases.


VAMPIRE 4, STANDALONE, and V1200 are very different cards and designed not by Igor but by the Apollo-team. These are different products with different features.

Posted on: 6/27 2:15
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:

cybergorf wrote:

It is also not helpful, if you delete posts in your forum,


If people post on Apollo-core forum without following some minimal behavior standards, then they get a warning.
If mishehavior continues, then posts will get deleted and people might get banned.

Your story is very simple: you were insulting, you got warnings, posts were removed, and you get a bann.
If you have question contact us via email or best by IRC.


Maybe this forum here could also benefit from some "cleanup".

Posted on: 6/27 2:06
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:

slicer wrote:
BigGun: is there any OPCodes still needed for SMP?
As I remember that 68k had TAS/CAS allready.


Apollo 68080 does support all CPU opcodes, also including
TAS, CAS, CAS2.

Old AMIGA systems did had a bus problem with using TAS/CAS on chipmem. TAS/CAS use a multicycle bus protocol and the AMIGA chip AGNUS could violate and interrupt this in the middle.
On old AMIGA using TAS/CAS was safe on fastmem but unsafe on chipmem.

The bus protocol is "fixed" on Vampire when using SAGA and the new "expanded" chipmem. With SAGA chipset it is now 100% safe to use TAS/CAS.


APOLLO 68080 is technically designed for SMP.
APOLLO 68080 has seperate ICache and Dcache.
The DCache runs per default in Write-Through mode.
Both DCache and Icache snoop memory writes.
This means both DCache and ICache are per design coherent to the memory.

When using single CPU core this means that the ICache supports selfmodifying code.

When using multi cores this means that all cores are coherent to each other.

Also SAGA provides what we call Magic-DMA channels.
There are programmable DMA channels which can be used for e.g. IDE transfer etc.

The M-DMA channels are coherent with the Caches of the CPU.
This means Icache and Dcache are again automatically updated. And the M-DMA channels use and honor the APOLLO MMU.
This means these DMA channels can NOT overwrite MMU protected memory regions and of course follow MMU mappings etc.

Posted on: 6/27 0:02
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
cdimauro,

you are either very mis-informed and are senselessly posting very wrong stuff
Or you are a liar and post on purpose FUD.



Lets clear some of the FUD up.

1) APOLLO 68080 is really 100% 68K compatible.
APOLLO does implement every 68K family CPU instruction.
Apollo does also implement all 68K family address modes.
Apollo is the only FPGA core doing this.
Apollo also supports all instruction which the 68060 does not support like e.g. MOVEP or MUL64

2) APOLLO has an MMU
This MMU is used many times on the VAMPIRE.
You use this when using MAPROM.
Its used when enabling "Chipmem Expansion"
On the Vampire you can virtually expend the chipmem and have 2/4/or even 128 MB chipmem also on Amiga 1000.

But an MMU is a complex feature.
The APOLLO MMU does offer more and stronger features than any of the old 68k MMUS.
For example you can "protect" memory not only from read but also from execution and you can use the MMU to shadow memory regions.
An OS not knowing all the features of the MMU could easily misconfigure it. As no 68K-MMU is compatible to the others MMUs of the family this is tricky for AMIGA OS 3. Therefore the APOLLO MMU is currently "hidden" and private until proper support to the OS is added. But maybe this support get easier added to AROS.

3) APOLLO can of course catch NULL-Pointer access and access to non-existing memory areas.
This feature is also available in the Vampire.

4) APOLLO has a full 80bit FPU including all instructions of the 68040 and 68060 Hard-FPU. All instructions are in operation and encoding 100% compatible.
But this FPU is in the Vampire2 not enabled currently as size fitting it in the FPGA requires more time and the teams is focusing today fully on bringing first out the new Standalone and new V1200 cards.


Posted on: 6/26 22:53
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Apollo will run 68000 code faster than any other 68K CPU.
I think there is no need to compile AROS for 68040 or so, AROS should fly on Apollo.

It looks to me more like there is some problem with AROS RTG on Picasso96..
AROS RTG looks slow.. a bit like running Windows in PC-Task ..

If this RTG/Picasso96 issue is "fixed" I assume AROS will feel many times faster.

not sure what the best approach here is...
Maybe doing a native AROS driver for SAGA would be the solution, maybe changing something in how AROS works over Picasso96 drivers.

An AROS developer would need to answer this.

Posted on: 2016/7/17 5:47
Transfer the post to other applications Transfer


Re: Aros Crash bug reports - Where to place?

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Quote:
I guess it depends on how fast the processor you use runs , but yeah an a600 should be as good as any.


The A600 is fast enough to in emulation boot Windows and use in - so our hope was that its fast enough for AROS too. :)


Thanks for your help to understand this better.
I'll email jason.


Posted on: 2015/1/13 1:32

Edited by biggun on 2015/1/13 1:55:32
_________________
......
Transfer the post to other applications Transfer


Re: Aros Crash bug reports - Where to place?

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 88
Offline
Actually we were only cross testing on UAE, as we thought all work work on UAE.

We in reality want to run AROS on A600 with 64 MB fast.
We figured that the A600 would be good to run AROS...

Is Jason doing the 68K port alone?
What would be the best way to contact him?

Cheers

Posted on: 2015/1/13 0:53
Transfer the post to other applications Transfer



 Top
(1) 2 3 4 ... 9 »




Search
Top Posters
1 paolone
paolone
4341
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3887
4 nikolaos
nikolaos
3677
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2623
7 mazze
mazze
2213
8 clusteruk
clusteruk
2097
9 Kalamatee
Kalamatee
2023
10 damocles
damocles
1789
© 2004-2017 AROS Exec