@cdimauro

Quote:

So using its APis for such tasks IMO shouldn't require a MEMF_PUBLIC only memory to be passed.

Memory might not always be present even if you have pointer to it, some memory might swamped out to disk, some memory might be private to a program, any type of memory can't be used for any condition.

In a hardware interrupt you do not want to waste time.

Last edited by NutsAboutAmiga on 26-Jan-2014 at 06:42 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

KimmoK wrote: Embedded SoC chips for Telecom nowdays need 64bit cores. (a few year old designs already needed 2GB just to say "tada", I expect modern designs to be far above 4GB of RAM. Main chips currently used are PowerPC and MIPS.)

My new home router/switcher/DSL box says it has 64M SDRAM and 128M Flash memory. It was currently running at 333MHz (which may be variable) but doesn't state the CPU or number of bits used. Judging by the low frequency and the fact that it only draws .5 amps max, I would guess it is ARM. You must be talking high end business/enterprise Telecom. I guess that is high end embedded also but I think mass produced consumer targeted usually when I hear embedded (though it doesn't need to be). I can see the problem for PowerPC/MIPS though. ARM (with Thumb 2) is getting more powerful and uses less electricity and memory while offering better developer tools and it's getting cheaper due to economies of scale. The super high end is 64 bit Intel where maximum processing power is needed. Economies of scale have made Intel processors cheap and powerful. As PowerPC and MIPS lose more market share, they will get more and more expensive due also to economies of scale. It looks to me like a death spiral for PowerPC. Obamacare has a better chance of pulling out of it's death spiral and that's between slim and none.

Quote:

cdimauro wrote: Again, unbelievable, since x86 was not a big win for the embedded market. May be the software complexity is so great now, that even a complex CISC is convenient in doing some tasks which in the past were in the complete RISC dominion.

I think the number one factor is economies of scale. They are absolutely huge in chip fabrication. Intel became top of the world because of economies of scale. Apple went from an absolute nothing to one of the top (three?) CPU manufacturers in less than 5 years. The best designed processor in the world can't compete with the worst if it's not being produced in quantity with a small die size and selling in the millions.

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: the confusion about MEMF_PUBLIC To solve the issue whit confusion of MEMF_PUBLIC, MEMF_SHARED in AmigaOS4.0 introduced, latter on its no longer program that should define the memory to used, now whit AllocSysObjectTags(ASOT_LIST, TAG_END), the memory type is defined by the OS.

What's the meaning of MEMF_SHARED?
Quote:

Quote: It's no true. They are publicly accessible, and even reading them is enough to hurt compatibility. That is not the biggest issue, the missing CIAA, CIAB, Paula, Alice chips is bigger issue,

Who cares? It's only useful for the old games, but UAE does a good job for this, and you don't need to be strictly linked to a very old chipset.
Quote:

besides some of ExecBase structure are now forbidden to read from according to AmigaOS4.0 SDK.

But 68K applications are "first class" in AmigaOS 4, and they don't care about the new guidelines introduced by AmigaOS4 SDK. I don't know when this SDK was introduced, but if it was late, it can be possible that some PowerPC applications don't follow the new rules.

Quote:

Quote: There's no need for a new flag, and that's from Amiga o.s. version 1.0. The thing is that AllocVec()/AllocVecTags() and AllocMem() return normal 32bit pointers, if MEMF_64BIT flag was introduced then function will need to return the memory byref in parameter (But normal tag lists are 32bit wide so it want work), my guess it that instead of creating this confusion, they probably make a new method for Exec.library called AllocVecTags64() or some thing like that. By having more methods, I belive the issue of where the memory is going to be allocated is solved.

The size of the pointers strictly depends on the "size" / ISA of the calling applications, so a 32-bit one will receive a 32-bit pointer, and a 64-bit one will receive a 64-bit pointer.

But it depends on the implementation. I think that a 64-bit application cannot use the existing 32-bit libraries, but should use their 64-bit counterparts. That's because the data structures are different, starting from the pointers size.

If you want to restrict in some way the address range of a memory allocation, I think that a flag similar to MEMF_24BITDMA can be introduced, but only for the 64-bit versions of AllocMem, AllocVec, etc.

Anyway, even this solution doesn't solve the problems which we discussed.
Quote:

Quote: But the performance will drop, as I stated before. PowerPC 64-bit ISA didn't provide huge benefits, like x64 and ARM64 gave, Well, 64bit wont give faster programs as you say, is half true,

It's fully true. Do you know of any ISA enhancement for 64-bit PowerPCs, that can reduce the performance loss?
Quote:

but there is a issue that is different on PowerPC the issue about Risk architecture is that some instructions are missing on G5, Pa-Semi chips, and normal 32bit program compiled for older PowerPC chip is not running optimal on the newer G5, Pa-Semi because of illegal instruction hits. Having binary’s that are optimized for G5, and Pa-Semi will be huge benefit, anyway the GCC 4.2.x we have is too old to take advantage of chips now. Basically we are seeing the same issues we did have on 68060 processor on G5 / Pa-Semi PA6T, and possibly on the QorIQ serials of CPU's

So this basically will contribute to the performance loss. It's a new, different issue.

And yes: it resembles the absurd decisions that Motorola did in the past; not only for the 68060...
Quote:

Anyway Microsoft has moved in different direction when comes to programing langauge for years, C# .NET and VB .NET, this are programming languages that live inside a runtime, and so memory, DLL library’s and OCX files all become C# classes, moving away from CPU dependency to a generic binary format that is compiled on runtime, allowing programs to not think about memory and all that.

No, the Windows applications don't have to think about the discussed memory issues in general; so, even for regular, "native" code.

.NET gives other opportunities and flexibility.
Quote:

NutsAboutAmiga wrote: @cdimauro Quote: So using its APis for such tasks IMO shouldn't require a MEMF_PUBLIC only memory to be passed. Memory might not always be present even if you have pointer to it, some memory might swamped out to disk, some memory might be private to a program, any type of memory can't be used for any condition.

Using MEMF_PUBLIC you'll solve all these problems, by definition. But it's not always desirable to mark every memory allocation with this flag, for the reasons that we discussed in the other messages. It should be used for message passing and sharing resources with "external / alien" applications, but otherwise it cripples the system, since this memory cannot be swapped, for example.
Quote:

In a hardware interrupt you do not want to waste time.

Primarily you don't want that your interrupt code could be swapped to the disk, especially in the middle of its execution.

@matthey

Quote:

matthey wrote: My new home router/switcher/DSL box says it has 64M SDRAM and 128M Flash memory. It was currently running at 333MHz (which may be variable) but doesn't state the CPU or number of bits used. Judging by the low frequency and the fact that it only draws .5 amps max, I would guess it is ARM. You must be talking high end business/enterprise Telecom. I guess that is high end embedded also but I think mass produced consumer targeted usually when I hear embedded (though it doesn't need to be).

It was high-end. 5K$ are not low-end by definition.
Quote:

Quote: cdimauro wrote: Again, unbelievable, since x86 was not a big win for the embedded market. May be the software complexity is so great now, that even a complex CISC is convenient in doing some tasks which in the past were in the complete RISC dominion. I think the number one factor is economies of scale. They are absolutely huge in chip fabrication. Intel became top of the world because of economies of scale. Apple went from an absolute nothing to one of the top (three?) CPU manufacturers in less than 5 years. The best designed processor in the world can't compete with the worst if it's not being produced in quantity with a small die size and selling in the millions.

That's a very good point.

Consider, however, that the chip production is becoming very difficult, even for giants like Intel.

@Birbo

The only list I can see is the list for those who pay 10k USD or more per year in membership fees. I doubt Trevor is one of those

_________________
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.

@cdimauro

Quote:

cdimauro wrote: POWER 8 can only be a post-Amiga machine dream. Quote: WolfToTheMoon wrote: @olegil yeah, Freescale doesn't have a single new PPC core planned, according to that document. I guess they'll just keep shrinking cores as new processes become available. Exactly. Despite of many claims of some people who don't want to accept the reality...

Noone here (as fas as I can remember) claimed Freescale had any new cores on the roadmap. Freescale is (as you are probably aware from previous discussions) busy with two projects:
1: finishing their T-series, which is what they call the 28nm process 64-bit POWER-arch SoC range. Most of these can be bought now, even though there are erratas to the current revisions. New revisions are in the works.
2: LayerScape A, which enhances the peripherals on the P and T series, and introduces ARM cores. The suffix A indicates ARM, and they are saying that they will have both POWER and ARM cores available.

I suggest reading http://cache.freescale.com/files/32bit/doc/white_paper/LAYARCHTECHOVWP.pdf?&Parent_nodeId=11824329976657261625E4&Parent_pageType=homepage as it has some good info.

Freescale does not see ARM as an improvement over POWER, they see it as a way of reaching those whose CEOs use an ARM-powered phone and therefore believes in the hype. It's extremely good for low power devices for the handheld world, but performance-per-watt is not the only metric out there

If you think about it for a moment, it's been a LONG time since Freescale last made a new POWER core, so why would it be busy making a new one NOW, when it JUST last year made e6500? Now is the time to USE the e6500. For crying out loud, they used the e600 (model number for the core previously known as G4) for 8 fricking years (first chip introduced 1999, last chip introduced 2007). If e6500 is any good, we should be using speed-upgraded versions of it for at least a FEW years before migrating.

Edit: Ok, maybe not so long time since last, as they made the e5500 (e500mc + 64-bit + e600 FPU) not so long ago. I also see that in another thread here I said the e5500 won't be as good as an e600 on FPU stuff, but if you don't use Altivec it turns out I was wrong there

But Freescale has not been doing the "new core every 18 months" (Edit: is it 12?) thing that Intel does. And I don't want them to, either.

Last edited by olegil on 27-Jan-2014 at 12:11 PM.
Last edited by olegil on 27-Jan-2014 at 10:12 AM.

_________________
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.

Some freescale material mention NG after the T series of QorlQ, but I'm sure there is nothing beyond just some vision. Most likely they see how world evolves and decide much later if new Power cores are worthwhile.
(so far they do not have any 64bit ARM to sell, or am I mistaken?)

(getting strong foothold in ARM arena is most likely crucial also for Freescale to have enough money to maintain their R&D department, as most CPU core business seem to be there in the future)

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

@KimmoK

ARM is not a CPU core business for Freescale, as ARM is not a Freescale CPU core

Freescale QorIQ ARMs will be completely different to what we think of as ARM chips, these will actually be useful for servers and desktops. But not for handheld devices.

Which is somehow a bit ironic. As in, it's a move that changes the market more than it changes Freescale. If it's successful.

In any case, I'm fairly certain the average Amigan would be quite content to have an SMP and Altivec enabled AmigaOS on an e6500, possibly on a higher clock than the current T series. The LS should bring that, if they ever get past the LS-A.

But I find it funny that LS1020A is a 1GHz dual-core A7 at under 3W, while the T1020 is a 1.4GHz dual-core e5500. The A7 has SIMD (Neon) while the e5500 does not (missing Altivec). But still, that ARM is gonna have an uphill struggle to keep up with the e5500. I think.

_________________
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.

@KimmoK

Quote:

(so far they do not have any 64bit ARM to sell, or am I mistaken?)

No, but they have the license for an ARMv8(64 bit) core, they will be making 64 bit ARM cores, which will be at least as fast as the fastest PPC core, if not faster.

_________________

@WolfToTheMoon

I attempt to disbelieve (that their ARMv8(64bit) will be as fast as their e6500, that is).

No benchmark result that I have seen points to anything like this. But I haven't seen a lot of benchmarks for the 64bit mode of ARM either.

ARM in 32 bit mode is WAY less efficient than POWER in 32 bit mode. POWER 64 bit has been a little less efficient than POWER 32 bit, due to some 32-bit thinking in the instruction set. All in all, I don't think ARMv8 is gonna tip the scales enough that a 1GHz ARM will beat a 1.4GHz POWER core if both have SIMD.

But the SIMD vs no SIMD is of course going to plague any chip Freescale bases around the e5500 core. I really think that's the stupidest decision of 2012. The stupidest decision of 2010 was the P4080 and the stupidest decision of 2011 was probably the P5020.

I guess you're seeing a pattern here

I don't see any issues with the T2080 and the T4240, though. Except for a SLIGHTLY stupid PCIe port muxing table, which is what I've come to expect from them.

_________________
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.

@olegil

some of the current faster ARMv7 implementations are already almost as fast as fastest (non IBM POWER)PPC cores, so assuming even a modest performance gains from ISA improvements I can say that faster ARMv8 chips will most certainly beat fastest non-POWER PPC chips - and be quite a bit cheaper.

http://www.7-cpu.com/

A quad core A15 at 1900 MHz is about as fast as a quad PPC970MP at 2.5 GHz.

_________________

@olegil

Attempt to disbelieve turned out to work great:

Quote:

Immediate generation replaces A32’s rotated 8-bit immediate with operation-specific encodings: o Arithmetic instructions have a simple 12-bit immediate, with an optional left shift by 12. o Logical instructions provide sophisticated replicating bit mask generation. o Other immediates may be constructed inline in 16-bit “chunks”, extending upon the MOVW and MOVT instructions of AArch32.

ARM previously used 4 instructions to generate an immediate 32 bit value (which means it really pays off to write the code differently, using a RAM address. Which could also mean that you get a cache miss, as there's separate I and D caches). A64 uses 2 or 3 for 32 bit and 4 for 64 bit, more or less exactly mirroring the POWER instruction set.

_________________
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.

@WolfToTheMoon

Quote:

A quad core A15 at 1900 MHz is about as fast as a quad PPC970MP at 2.5 GHz.

And a quad PPC970MP at 2.5 GHz is about as fast as a quad Atom Z3770 at 1.46GHz, according to that table. Just to put that comparison into perspective. In case anyone wonders why I'm not on the ARM bandwagon just yet.

You failed already at "fastest (non IBM POWER)PPC cores". The e6500 core is much faster than that (even e5500, e500mc and e600 are faster than the 970 when it comes to instructions per clock). 6 DMIPS per core (multithreading). So 2 cores with multithreading at 1.8GHz for the e6500 would already beat a quad 2.5GHz 970. And you can only get it with 4, 8 or 12 cores

Also, that's a benchmark of SYSTEMS, not CORES. The same core used with a different memory bus can give a completely different result. Depending on the data size.

Also, I don't know whether that benchmark uses SIMD, which it probably should. The e6500 Altivec is MUCH more useful than the one in the 970, primarily because it can be fed data from RAM. This was always a huge problem for Altivec. Not so much of a problem anymore. Some interesting curves in this respect are on http://lqcd.fnal.gov/g5/

It's fairly easy to see that SMP didn't help for Altivec there. At all. And the G5 used had a sucky memory interface compared to the P4. So Intel was ahead on memory bandwidth but behind on vector math.

I expect a 2GHz version by the end of the year. I also really wish Freescale would get an incentive to make a desktop version (you know, just put silly amounts of cooling on it and see how fast it goes) rather than just the 50W targets they're doing now.

So, to summarize the summary of the summary: If anything, I would go x86. ARM is awesome for handheld devices, but just cannot compete on the desktop.

_________________
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.

@olegil

Quote:

And a quad PPC970MP at 2.5 GHz is about as fast as a quad Atom Z3770 at 1.46GHz, according to that table. Just to put that comparison into perspective. In case anyone wonders why I'm not on the ARM bandwagon just yet.

Intel is faster, yes, but I was primarily making comparions PPC vs ARM.

Quote:

You failed already at "fastest (non IBM POWER)PPC cores". The e6500 core is much faster than that (even e5500, e500mc and e600 are faster than the 970 when it comes to instructions per clock). 6 DMIPS per core (multithreading). So 2 cores with multithreading at 1.8GHz for the e6500 would already beat a quad 2.5GHz 970. And you can only get it with 4, 8 or 12 cores

e6500 core has only recently been made available in quantity. And it's very expensive.
Applied Micro, Caveon, AMD and others will soon be able to sell you a 64 bit ARM Cpu with up to 48, even 64 cores... even more is planned... PPC simply cannot compete, even if it were to be slightly faster core per core, which I very much doubt.

On desktop, both are equally bad, IMHO. It's just that ARM is so much cheaper that you can easily forgive it if it doesn't have all the neccessery stuff you'll find on a off-the shelf (mini)ITX x86 board.

_________________

@matthey

Quote:

Couldn't new apps use a new memory allocation memory attribute like MEMF_64BIT to allocate 64 bit memory while old apps would continue to get allocated memory in the 32 bit addressing range? The OS and structures without changes (other than 64 bit memory allocation functions) would all be allocated in 32 bit address space for compatibility.

You would need to tweak the compiler and add another __attribute__ stating "this is a 32-bit pointer". Otherwise code compiled for 64 bit would never know it the accessed pointer is 32 bit or 64 bit long.

Keeping system data away from any access by the user software is the key for simultaneous 32-bit and 64-bit compatibility, or, e.g. for mixing of big- and little-endian code (just like Rosetta for OSX did). As soon as system exposes all its internals to the 3rd party, one will have to provide "shadow" versions of system structures for each supported architecture.

PS. Windows, just like linux, supports 32bit software on 64-bit system by providing separate collection of 32-bit libraries (ask google for WoW64 for details) which are a thin wrappers if possible, or complete 32-bit replacements for the 64 bit dlls. OSX does similar, but it's hidden from the user behind the so called universal (or fat) binaries, just like in this tiny example:

michal$ otool -fv libpam.2.dylib
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 4096
size 35872
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
capabilities 0x0
offset 40960
size 35392
align 2^12 (4096)

Last edited by michalsc on 28-Jan-2014 at 10:59 AM.

@WolfToTheMoon

"It's just that ARM is so much cheaper "

32bit low end ARM chips are cheap.
Let's see how high end chips will be priced...

(and the price of the CPU/SoC chips is not what makes Amigas expensive)
(btw. cheapest e6500 based SoC chips should be less than half of PA6T price but with 4* the performance)

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

@KimmoK

Quote:

32bit low end ARM chips are cheap. Let's see how high end chips will be priced...

For AmigaOS4, 32 bit is all that matters.

MorphOS might end up supporting 64 bit if/once it changes ISAs

AROS/ARIX already supports 64 bit on x64

Since P3041 is 32 bit only, I can see that A-eon/Hyperion do not have any mid or short-term plans for 64 bit support.

_________________

@WolfToTheMoon

And since P5020 is 64 bits capable, I predict that A-Eon at least have a short-term plan of releasing a 64-bit system. Or even more to the point, the X1000 already had a 64 bit CPU. So that's a long term history of 64 bit systems. Hyperion are of course a separate entity here.

I predict that this is turning into a circular argument.

_________________
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.

@olegil

Quote:

And since P5020 is 64 bits capable, I predict that A-Eon at least have a short-term plan of releasing a 64-bit system. Or even more to the point, the X1000 already had a 64 bit CPU. So that's a long term history of 64 bit systems. Hyperion are of course a separate entity here.

I don't really see a need for a 64 bit release of OS4, especially if it would split the userbase in half(since only newest A1, minus the P3041, would be able to use the questionable benefit of 64 bit PPC)

_________________

@WolfToTheMoon

Stating that X core is faster than Y core based on one benchmark is a bit short sighted.