@Tuxedo

Quote:

Tuxedo wrote: @Spectre660 so... plz tell us also blender benchmark plz on sam460 and also Tabor wirh same Blender version... Maybe 2.48... And tell us if was DSP optimised on Tabor, thank you!

AFAIK the e500v2 has no DSP extensions.


@itix

Quote:

itix wrote: @Overflow I dont understand Jens comment. The FPU is not an isolated co-procesessor but part of execution flow. If it was emulated on second core there would be great overhead to synchronize fpu instructions. His proposal can't work.

Absolutely. Using the second core to offload the FPU exceptions of the first doesn't make sense at all, if the purpose is to accelerate the FPU emulation.

Quote:

itix wrote: @Overflow I like that people is throwing new ideas. It is always appreciated. He just didn't think it through. There just is too much overhead and also ABI compatibility issue remain unanswered.

I think that the ABI compatibility can be achieved emulating the normal FPU. But, of course, it slows down a lot the execution time.


@Overflow

Quote:

Overflow wrote: @itix Indeed. Maybe he sees possibilities that others have missed, or maybe you are right that he didnt think it thru. I just took notice since its a comment made by Jens, that have more depth of knowledge hardware wise than Ill ever get. As for OlafS25 comment about Jens missing the "single core" aspect of the OS;

It's not a question of single or multiple core support of the o.s.. The problem here is that if the first core traps due to a not-implemented instruction, it switches to supervisor mode, and this takes some time. Then it should take the offending instruction, "contact" the second core, give to it such instruction, let it process it, and then wait until the computation is done. That's because the first core CANNOT continue executing code with the following instruction, because it has to wait for the completion of the unimplemented one, due to the strict synchronization of code flow.

Yes, we know from long time we have out-of-order processors, but trying to emulate such behavior at the software level creates much more problems that a simple trap-and-emulate solution already does (because emulating a FPU isn't a trivial task itself).

In short: FORGET the idea of offloading the FPU emulation to the second core. itix is totally right here.

@Tuxedo

When Freescale itself says FPU implementation in e500v2 core is weak (in comparison to "classic" FPU eg. in e600/e5500/e6500), I wouldn´t expect great result in heavy FPU depending benchmark like Blender. However, Blender can use both cores of P1022, so it may beat 460EX.

@cdimauro

I am not a hardware guy... this theoretical switch from one core to the other due to not implemented instructions would need to be implemented in the hardware?

@Overflow

Quote:

Besides, it's not all-incompatible, but throws a few illegal instruction traps on commands not implemented (according to one of the developers I talked to last saturday). That's about the same as what the 060 CPU does for unimplemented commands of the earlier members of the 68k group. Would you make fun of those who designed with the 060 back then? Surely not.

I'll trust Jen's expertise. Hopefully there's no hidden issues such as not being able to do such trapping in Coldfire for a faster 68k Amiga...


Wouldn't it be cool if something like Qemu was built into whatever loads program files into memory for execution? Then, as I understand (and I might not understand correctly), the binary is effcetively recompiled to the host CPU, or perhaps it's a JIT to the host CPU, to give us near-native speed ABI compatibility...

_________________
All glory to the Hypnotoad!

@OlafS25

Quote:

OlafS25 wrote: @cdimauro I am not a hardware guy...

Me too.
Quote:

this theoretical switch from one core to the other due to not implemented instructions would need to be implemented in the hardware?

Only if you want to accelerate it.

However if the second core is exactly like the first one, it doesn't have any sense to do such contorted operation. I mean: there's absolutely NO advantage of doing that, but only a big performance problems due to the dispatch & synchronization operations which are ADDED to the mere instruction emulation operations.

Really, it's non-sense.

We aren't talking about using the second core as a coprocessor, to dispatch operations like graphic update, disk handling, and so on, where such approach will have some gains for sure (IF correctly implemented).

@cdimauro

Quote:

I think that the ABI compatibility can be achieved emulating the normal FPU.

This mean the executable (or the compile unit) must target a normal PPC FPU, however, to get right instructions generated...

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Overflow

Quote:

Overflow wrote: Noticed Jens Schoenfeld made a comment regarding the CPU; Quote: The P1022 is a dual-core CPU. Even if you were to emulate all FPU commands in software, you'd have a spare core to do that, as OS4 is still a single-core OS. Besides, it's not all-incompatible, but throws a few illegal instruction traps on commands not implemented (according to one of the developers I talked to last saturday). That's about the same as what the 060 CPU does for unimplemented commands of the earlier members of the 68k group. Would you make fun of those who designed with the 060 back then? Surely not.

I forgot to reply to this. Yes, I never liked Motorola craziness about changing the supervisor mode (basically) with each processor. And I really hated her when she decided to do it also in the user mode, with the 68060, removing instructions...

@cdimauro

I am not aware that the AmigaOS camp is able to detect additional cores and use them at all and that would be needed to do that at all on software level. I know that the aros devs have managed to do that. Other than that not everything even skilled persons say is necessarily well thought and true. We will see who is right as soon AmigaOS runs on it.

It sounds a little like multithreading... rather theoretical here

Last edited by OlafS25 on 16-Oct-2015 at 03:51 PM.

@itix

Quote:

itix wrote: @cdimauro Quote: I think that the ABI compatibility can be achieved emulating the normal FPU. This mean the executable (or the compile unit) must target a normal PPC FPU, however, to get right instructions generated...

My idea is to use trapping only when APIs using such ABI has to be called (from application side). Then trapping them, and when the API is effectively called, use the SPU unit to do the real work.

It'll keep retrocompatibility, at the expense of some slowdown.

Just a quick idea. That's all.

@OlafS25

Apologies If I insult you in any way...
Actually I am writing this from my Icaros Dectop 2.03 pc so I have an open mind about all flavors off nex gen amigas .
And believe me I am very enthousiastic about Icaros I am just after using mos for about a year and a half and invested in a G5 and a registerd mos version for my peg II want the "real thing" beside its problems and still unresolved many stupid bugs .

And again I own all three nex gen flavors off amiga operating systems so I can express my likes and dislikes after using all of them for over a year .

I just do not like it .. its user interface is not workbench but I again express my personal opinion ...

@50mm

I know I saw it one time... ambient is ambient and not workbench

everybody has different taste. I use magellan and like it with all the configurations that are possible, others hate it whyever (and have never explained it).

I have only reacted to "clones" because it is simply not true. All are heading in different directions, implement different components. At the moment Aros and MorphOS are similar in some areas but that will propably change in future. Aros is at best a 3.1 "clone" reimplementing the API but has also many additional components. The same is true for MorphOS. Both projects were partly long started before 4.X even was in discussion.

@Everblue

Quote:

I seem to be hearing a lot lately about Morphos coming for x86, but most probably it is years and years away from happening.

Indeed. One of the problems with x86 is that it's a constantly moving target. Just coming up with a reasonable set of drivers alone will be a massive effort! And even if the MorphOS developers manage to pull it off, the net result will still be a niche OS for hobbyists that can only support a small, pre-determined subset of common PC hardware (see Haiku, AROS, etc.).

Now don't get me wrong. I'm not saying that's a bad thing. Only that x86 is not the panacea for attracting the "masses" back to Amiga-esque platforms that some think it is.

Last edited by Alloye on 16-Oct-2015 at 04:47 PM.

@OlafS25

Quote:

started before 4.X even was in discussion.

I don´t think AROS or MorphOS are there since 1992.

@OlafS25

Thank you for your response .
The most anoying thing about Icaros for me its that amistart has too many menus ...
believe it or not I am still feel lost with them there are too many choices

@pavlor

never heared of that, thanks for correction

but even if they use 4.0 Hyperion and 4.X was certainly not predictable

@pavlor

It's funny that 20 years ago there were already dicussions about memory protection... and that 20 years later nothing has changed :)

Quote:

3.0 has nothing to do with the general improvement of the OS. It's a release for support of the AGA chipset. 3.1 will be important, because it will include networking (TCP/IP) and DSP support. 4.0 is when we really take off. I'm also silently hoping that by 4.0 the OS has some sort of memory protection on the MMU equiped processors, but I'm not getting my hopes up.

Last edited by Leo on 16-Oct-2015 at 04:22 PM.

_________________
http://www.warpdesign.fr/

@50mm

Amistart is configurable so you could adapt it.

The problem with both Magellan and Icaros in general is that you have to read manuals

Normally you do not need the menues of amistart as long as you do not want to change it.

on the download-page is the manual (PDF):
http://vmwaros.blogspot.de/p/download.html

really worth to read if you want to configure all properly.

I have also published the magellan-manual:
http://www.aros-platform.de/html/magellan.html

useful if you want to change something yourself

Last edited by OlafS25 on 16-Oct-2015 at 04:36 PM.
Last edited by OlafS25 on 16-Oct-2015 at 04:17 PM.

@Leo

at least one constant

@Leo

Some memory areas are protected since 4.0... Not that it changes basic truth of your statement.


OS4.0 was dream project of every Amiga owner: Commodore, Escom, Gateway, Amino: all announced OS4 with various intended features. It took more than 10 years after such first discussions until Amiga OS 4.0 was released to public.

@Alloye

there is no easy way to attract the masses again. Even if you have a modernized platform it still misses most of the huge software base you have on the big platforms and to really attract new people you would need really new software and services that not exist on other platforms.