@pavlor

I would say it depends on the task and how transparent is the integration

@pavlor

Quote:

Dead CPU architecture as common ground for dying OSs? I don´t think 68k is well suited for that task - modern CPU architectures need 64 bit, SMP and memory protection, that are realy hard tasks for 68k assuming main 68k platform is today WinUAE (single core, no MMU with JIT).

thats all we have in common, and 99% of the legacy. see it as virutal machine layer like java.

what concerns 64bit, smp and memory protection which ng amiga alternative provides those currently? simple answer: none.. oh, wait, there is 64 bit version of aros. what concerns smp, well, i guess there might be something in the air..

@drstrangelove

Quote:

@wawa .... more or less I put only to emphasize the need to forget the name of the processor ....

okay, but by now we know it cannot be just something completely abstract, out of nowhere, like amigade. so whats your alternative?

@wawa

Quote:

what concerns 64bit, smp and memory protection which ng amiga alternative provides those currently? simple answer: none

PowerPC (and x86) CPUs at least offer infrastructure for these features, unlike WinUAE 68k JIT.

if the 68k code is executed on those cpus it can take advantage of the infrastructure alright, doesnt it?

Last edited by wawa on 17-Mar-2013 at 10:49 AM.

@pavlor

I do not see why there is a conflict. On Icaros 68k runs transparent in a sandbox so you can have 64bit, SMP and so on without any problem. On the 68k side you have 24bit colour and stereo, lots of RAM and speed much faster than any classic so you can create goodlooking and demanding software too. When you need fullspeed (f.e. for 3D gaming or certain very demanding applications) you need "native" applications. So it is a decision by the programmer what he needs. But 68k seeing automatic equal to slow and oldfashioned is wrong in my view. I talk here about AROS (with Amibridge and UAE).

@OlafS25

Quote:

so you can have 64bit, SMP and so on without any problem

With x86 binaries, not with 68k ones.

Quote:

But 68k seeing automatic equal to slow and oldfashioned is wrong in my view.

68k applications can´t use more cores, so on 4 core CPU they can use only 1/4 of available performance. Even with capable JIT (eg. 1/5 of native speed) you will waste (in some cases) 95 % of CPU speed.

@pavlor

I tested Cinema4D with JIT (WinUAE) and it rendered a picture in less than 10 seconds. So when you have JIT and transparent integration it is really fast even without using all cores. In X86 we talk about more than 3 GHz.

Last edited by OlafS25 on 17-Mar-2013 at 11:12 AM.

@pavlor

68k applications (under JIT) can use extra cores just as much as x86 or x64 apps.

Read when there is an actual API supporting it *doh*

68k applications can't (fully) use more than 4GB per app, but that the only real difference in term what is possible with 68k vs. other code.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@pavlor

On a german forum I read about a new game that is in development that needs 68060 and RTG. But most developers want the software to run on A1200 with AGA and 68030 (at highest). It is more a limitation by the developers than a problem of the available hardware.

But as I said it depends what you want to develop.

@Fransexy

Quote:

2- there is not (not much at least) desktops computers with Arm so it's a niche to conquer; you know, who strikes first strikes twice. There is more sense for and custom dektop Arm than a custom desktop x86

Yes, there aren't desktop computers with ARM (or, more precisely, there are some netboks but their numbers are scarce). Have you ever wondered why?

@OlafS25

Quote:

I tested Cinema4D with JIT (WinUAE) and it rendered a picture in less than 10 seconds.

Cinema4D is sort of software that would benefit from multiple cores, you realy waste 95+ % of CPU speed in this case.

@paolone

Quote:

there are some netboks but their numbers are scarce). Have you ever wondered why?

When the X86 netbook market died it took the other netbooks with it.

@pavlor

Yes of course a native version running on a system with multiple corse (and using them) could be much faster. I only wanted to show with this example that you can do lots of things with 68k too.

@OlafS25

Quote:

I tested Cinema4D with JIT (WinUAE) and it rendered a picture in less than 10 seconds

What was the actual test? Less than 10 seconds is meaningless if we know nothing of the scene or settings used.

@persia

Quote:

persia wrote: @paolone Quote: there are some netboks but their numbers are scarce). Have you ever wondered why? When the X86 netbook market died it took the other netbooks with it.

Ack!
Beside of low spec boards like the RasberryPI there are not much desktop like ARM boards available.

Most ARM systems are designed as smartphones and tabletts and there is no AmigaOID OS that has a GUI suitable for finger controlled touch screens. And even if the GUI would be anhanced for such type of handling (imagine no pull down menus, thick buuton, multi touch, ...) you have to rewrite all applications to run on this new GUI.

So (as I and many people pointed out before) there is not much sense for AmigaOIDs on ARM except you don't want more performance than a Sam460 could deliver.

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@Rob

Ham8 and picture is here at the end of the site (the globe):

http://www.natami-news.de/html/user_manual.html

@megol

Quote:

megol wrote: Supporting big endian code on x86 is easy, have been easy and have been done a number of times. In fact there have been a JIT 68k40 -> x86 available on the market before AOS4 was conceived (don't remember the name ATM).

JIT is not a problem solver, it is just an emulation technology. It might run some things faster but i won't make them run better.

The main problem is somewhere else:

68k programs are accessing the system structures in 68k byte order.
x86 programs are accessing the system structures in a x86 byte order.

So both system can't access the same system structures.
Even the emulator doesn't know when a 68k structure will be needed in an x86 byte order.

Well you can't change the programming API on 68k software because most of it is not supported any more.

So you would need some kind of sandboxing more complex than the 68k emulators on UAE, MOS or AOS4 does. And even Rosetta on OSX did not provide a full transparent emulation, it could not run 68k drivers for scanners on x86.

But there might be a solution for this problem, you should aks how many old programs are used that can't work under UAE. For example JUAE on AROS might be a good example how the 68k support could be done today. It will not support 68k drivers for scanners over the emulation but it will support most 68k applications and games.

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@royleith

Quote:

royleith wrote: What do you think? Please; no processor rants. We've already done that! Regards Roy Leith

Well that fell on deaf ears didn't it...

Sometimes think instead of starting new threads on this strange subject about something that's never going to happen and people posting the same old replies over and over again...

Why not just pick out an old thread from years ago on the same subject, lock it and make it a sticky on the front page...

After all, there's never anything new said in these threads, it's like the Amiga version of Groundhog Day only without the humour...

_________________

@Franko

Quote:

After all, there's never anything new said in these threads, it's like the Amiga version of Groundhog Day only without the humour...

...and the beggar who always dies no matter what, it's Amiga itself.

Last edited by resle on 17-Mar-2013 at 12:40 PM.