@OlafS25

They aren't investing in ARM, they're licensing it. The thing they're investing in right now (and I've said this before) is the rest of the SoC design, going from the T to the LS in the QorIQ family. It's a die-shrink and a redesign of the peripherals for higher IO performance.

LS-A will use ARM, LS-P with POWER cores are on the roadmap, last time I saw the roadmap.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@OlafS25


There is NGCore in the PowerArchitecture roadmap of freescale. (far in future as e6500 is just coming out)
And things like 20-40 * e6500 core layerscape SoCs
So far the ARM64 based layerscape SoC chips in the roadmap do not seem to outperform the high end e6500 powered models of the same roadmap.
(from some (training?) material from October 2013 or so)

>...even emulated 68k can already outperform SAM 460, that shows how far ahead Intel/AMD performance wise already are.

PPC460 is based on 10+ year old core?
And IIRC, a few days ago I saw emulated PPC perform like a few hundern Mhz PPC on high end i7 ...?

There is younger PPC cores becoming available. Cyrus with e5500 and then there is e6500 to explore.
I think there is life after 68k and beside x86. Even when we do not outperform x86 (we do not need to).

Emulated PPC is not a solution in any case.
Changing ISA could be (but let’s not restart that discussion, please).

MORE:
What we need (HW wise) for AOS and MOS, is a affordable HW in production.
A HW that can process modern apps in acceptable speed.
(IMO: modern Atom chip level of performance, perhaps, as it seems able to manage everyday things ok to be usable. And similarly my 2Ghz AMD64x2 seems able to do everything I thow at it (My FX4300 does not seem more usable or radically faster). )

SW challenges are bigger.
We need to use multicore efficiently (no matter what ISA is used for NG).

Last edited by KimmoK on 21-Feb-2014 at 12:13 PM.
Last edited by KimmoK on 21-Feb-2014 at 12:11 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

You mean PPC is undead?

hopefully AROS and MorphOS will become available on SAM/X... so the hardware discussions will then end. Discussing about ISA changes do indeed make no sense because the only person that decides is propably not reading it (and taking part in discussions).

I personal think that you do not need live after 68k because there is still life in 68k

FPGA based solutions (standard hardware) would not outperform standard PCs but they would have some "geek factor" and together with other 68k options like UAE running on fast hardware would still offer some opportunities. I do not think it is that "retro" like many of the NG fans think. And thanks to UAE it is almost running everywhere (and very fast).

We need big standardized platforms that offer easy distribution and a big number of users. That was basically what I try to do with my distribution.

Last edited by OlafS25 on 21-Feb-2014 at 12:17 PM.

@KimmoK

MOS

Last edited by itix on 21-Feb-2014 at 12:49 PM.

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

@KimmoK

Quote:

What we need (HW wise) for AOS and MOS, is a affordable HW in production.

You mean sub-$200 hardware renewed every two years sold near you? Because it is not just about price.

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

@OlafS25

Quote:

and even emulated 68k can already outperform SAM 460

Not if MMU support is requirement (as in case of any modern OS).

Quote:

Do they still invest in high-performance PPC processors?

There seems to be new products in the QorIQ portfolio:
T1020/T1040 - two or four core SoC based on e5500 cores up to 1.4 GHz (same core as in X5000). Situated in value-performance segment. Still preproduction.
T2080/2081 - four core SoC based on e6500 cores (2 threads per core) up to 1.8 GHz. Mid-performance. Still preproduction.
T4160/T4240 - 8 or 12 core SoC based on e6500 cores (2 threads per core) up to 1.8 GHz. High-performance.

Coremark score of T4240 1.8 GHz for one thread is 7490, for comparison PowerPC 970 1.8 GHz scores 3988. However, these results may or may not be directly comparable.

@pavlor

Sorry it was about comparing speed of 68k software running in emulation versus other NG platforms. MMU is only partly supported by WinUAE (when JIT is disabled) so then it is slower. But when you play a game why do you need MMU? I know what MMU is for but here it makes no sense.

@OlafS25

Quote:

Sorry it was about comparing speed of 68k software running in emulation versus other NG platforms.

I certainly wouldn´t call platform without sensible MMU support as NG.

Quote:

MMU is only partly supported by WinUAE (when JIT is disabled) so then it is slower.

Much slooooooower.

Quote:

But when you play a game why do you need MMU?

I bet your AROS68k distribution was not meant as simple game-launcher.

@KimmoK

Quote:

Did not know CBM designed any CPU. (links to learn would be nice)

MOS was designing a 16 bit CPU to rival 8086, 68000 and Z8000 around 1980. The design didn't come far before it was cancelled.

Synertek, second source for MOS tech., developee an improved 16 bit version of 6502 in around 1978 timeframe.

Quote:

Around August, 1978, one of MOS Technologies' second sources, Synertek, began circulating specifications for a new 6500 microprocessor called the 6516. This chip was a pseudo-sixteen bit processor designed to compete with the new Motorola 6809 microprocessor. This chip introduced a few new addressing modes and several new instructions. Probably the most unique thing about it was that it used a set processor status register bits to control whether or not the A, X, and Y registers, or memory operands operated in eight or sixteen bit mode. The (previously) unused bit in the P register became a user flag in the 6516. The 6516 sported sixteen-bit accumulator, X, Y, PC, and SP registers. It also incorporated an eight-bit "Z" register which controlled the location of the zero page. In terms of addressing modes, the 6516 supported the following addressing modes: - immediate, - implied, - register, - direct page, - direct page indirect, - direct page indexed by X, - direct page indexed by Y, - direct page indexed by X indirect, - direct page indirect indexed by Y, - absolute, absolute indexed by X, - absolute - absolute indirect - absolute indexed by X - absolute indexed by Y - 8 and 16 bit relative The instruction set included all of the 6502's instructions plus LDZ (STZ), LDS (load SP), LHA (load H.O. A byte), LHX (load H.O. X byte), LHY (load H.O. Y byte), LAX (load A from location pointed at by X), SAX (store A at (X)), LAY/SAY (load/store A at (Y)), ADD (no need to clear carry), SUB (no need to set carry), INC/DEC accumulator, TAZ (init Z register), TZA (get current Z register value), YPC (transfer Y to PC -- JMP (Y)), PCY (copy current PC into Y), XHA/XHX/XHY (swap A, X, and Y halves), XXY (exchange values in X/Y registers), SEF/CLF (set/clear user flag), LDQ (load "Q" processor register with an immediate value), SEV (set overflow flag), AXA/AYA (add X/Y to A), AAX/AAY (add A to X or Y), AMX/AMY (add memory to X or Y), NEG (negate accumulator), several new shift and rotate instructions including RLT, RRT, ASR, RHL, RHR, RXL, RXR, RYL, and RYR, BFS/BFC (branch if user flag set/clear), JNE/JEQ (jump long if not equal/equal), PHD/PLD (push/pop 16-bit A), PHX/PHY/PLX/PLY/PHZ/PLZ (push/pop X, Y, and Z registers), PHR/PLR (push/pop all registers), BR1..BR5 (five new] BRK/software interrupt instructions). In addition to the new instructions, Synertek enhanced several old instructions by adding new addressing modes. They also reduced the number of cycles needed to execute various instructions, for example, many implied addressing mode instructions took only one cycle (rather than two) on the 6516.

Last edited by WolfToTheMoon on 21-Feb-2014 at 03:55 PM.

_________________

@pavlor

What other application need MMU? I have lots of applications (former commercial) in my test environment and all are running without MMU. Or do I miss something?

@pavlor

Quote:

Quote: Sorry it was about comparing speed of 68k software running in emulation versus other NG platforms I certainly wouldn´t call platform without sensible MMU support as NG.

You dont really need MMU. It can be used to protect kernel space but on Amiga everything is running in userspace so it is not really relevant.

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

@itix

Quote:

You dont really need MMU.

Or FPU, or HDD or...

@pavlor

I dont know why you say that. FPU and HDD are useful, MMU not so much.

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

@OlafS25

Quote:

What other application need MMU?

If your goal is to keep forever out-dated memory management features of Commodore era - then you certainly don´t need MMU. Anything above (memory protection, virtual memory addressing or even support for multiple cores) is out of question.

WinUAE does well its job as emulator of classic Amiga, but it looks in past, not in future.

@pavlor

It is not possible add true memory protection to Amiga operating systems without breaking compatibility with current software. Multicore support is there already (blitter, copper and PowerPC co-processor can be considered as multicore support). Virtual memory addressing is not important because you cant introduce isolated address space (or you break current software) and you dont need virtual memory when you can have more RAM than 32-bit applications can address.

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

@itix

Quote:

It is not possible

Exactly as I wrote: looking in past, not in future.

@pavlor

If you are looking to the future then you are on wrong forum. Amiga is retro. It has inherit design flaws you can't fix unless you rebuild it from ground up. In that case your choice of CPU would be x64 no matter what.

Last edited by itix on 21-Feb-2014 at 04:44 PM.

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

@pavlor

FPU is supported and not slowing

as far as I know is the apollo core without MMU (and also not planned) and the FPGA Arcade has no MMU either so i do not care about it right now. Memory protection for 68k without (heavily) breaking compatibility? Multiple cores support will be interesting perhaps someday but that is far in the future right now. Any 68k environment is certainly not main system for most users, mostly just for fun running either in emulation or on FPGA or even on real hardware. It is realistically no competition to Windows or Linux today. It is a kind of playground . I just thought how much RAM theoretical can be addressed from AROS 68k? 4 GB?

@pavlor

when you need something "more in the future" then f.e. AROS X64/X86/ARM/PPC is more interesting to you (with 128 GB RAM supported on X64). 68k needs compatibility to existing applications, breaking compatibility would be not a good idea.

@itix

Quote:

If you are looking in the future then you are on wrong forum.

Then why threads like this?

Quote:

It has inherit design flaws you can't fix unless you rebuild it from ground up.

I applaud all people who keep trying.