@thread

If we extend my estimates in the Tabor thread to the e6500 cored T2080 @ 1.8 GHz.

Minimum 3.3 drystone per MHz for 5940, UNTIL core count and threading is taken into account.

P5020@2.2GHz=6600 x 2cores x 1 thread=13200

P5040@2.2GHz=6600 x 4 cores x 1 thread=26400

T2080@1.8GHz=5940 x 4 cores=23760 x 2 threads=47520

Keeping in mind that these are idealized figures that are only for straight comparison.

SO, if we had SMP support, almost twice the performance per processor core.
And about 90% of the single thread performance.

On a cheaper CPU.

@iggy

Don't worry about "if we had SMP support". Either we will or we wont at somepoint, but if the CPU doesn't have it then of course we'll never get it.

hardware first, then hopefully software. Otherwise, never ever that software... You can't do the software first...

Some argue that it's stupid to do some hardware thing before the software supports that hardware thing...

Besides, regardless of if we have SMP ever or not, if T2080 is cheaper than processor-X, then it's still a good choice for an economy board than processor-X is, regardless of how many cores processor-X has compared to T2080. T2080 will work fine with a single-core OS.

So don't choose a lower-core processor based only on the fact that OS4 is today a single-core software. Consider the possibility of software's future as part of your criteria in whatever you select for your design, lest you lock yourself out of what might be a better price/performance ratio when/if software does catch up to SMT.

Just some thoughts, as you may see others talking about SMP numbers being completely bogus or useless and we should all completely ignore that hardware possibility for any and all considerations forever.

_________________
All glory to the Hypnotoad!

@billt

Quote:

billt wrote: hardware first, then hopefully software. Otherwise, never ever that software... You can't do the software first...

Heresy! It's heresy I say.

Hardware before software. HAH!

_________________
Tinkering with computers.

@Signal

Quote:

Hardware before software. HAH!

I thought that was already an OS4 tradition.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: The same happens also to the PowerPC apps, when moving to a new architecture (included PPC64). If you interested in this look it up, lots of info on how this works on Windows. You don't need Windows7 32bit emulator to run a 32bit program in windows7 64bit. At least works transparent too me.

This argument was already raised several times, and I've always reported that the Windows (as well as other o.ses) approach cannot be taken as an example of what could be done with the Amiga/like o.s..

So, no: introducing 64-bit support WILL KILL the backward compatibility with the existing software (both 68K and PowerPC).
Quote:

Quote: How about memory protection, 64-bit, resource tracking, and SMP? Aren't they "the bare minimum" nowadays? You don't need memory protection to use a program, it's not requirement.

Sure. You can continue to live with an environment which can be brought down by any user application.

However a serious o.s. wouldn't allow that, and protects both itself, its drivers, and any other application from a bugged and/or dirty user software.
Quote:

64-Bit, is just bigger registers on PowerPC, and larger address space, most programs don't need it.

So you don't even need an horrible patch which introduces the infamous bank-switching of the 8-bit era, right? Guess WHY this anti-Amiga o.s. feature was introduced...

Anyway, even graphic cards have more than 2GB, which needs to mapped to the address space, which is common to everything (so, included the graphics memory) in any Amiga/like o.s.. But if you like to still use 128 or 256MB of graphic memory even if your card has 8GB, and stick to lower resolutions and/or graphic details, well, you can continue this way, eh!
Quote:

SMP is transparent to the program, program does not need to know about it, The kernel just schedule programs, and threads on different cores, that’s it. Of cause memory has to be synchronized, but that’s a feature of the OS, not the program.

Right, and that's A BIT difficult to achieve with a Forbid-based o.s...
Quote:

Colors and resolution is something you see with your eye, the other things you talk about does not affect the picture your trying to draw or music you're playing.

Well, they will for sure. A trivial example: a modern game which uses more than 2GB just for the textures.

But, yes: you can continue to live on the technological cave where you imprisoned yourself, because of the prehistorical Amiga o.s. limits.

Only Amiga makes it possible...

@billt

Quote:

billt wrote: @iggy Don't worry about "if we had SMP support". Either we will or we wont at somepoint, but if the CPU doesn't have it then of course we'll never get it. hardware first, then hopefully software. Otherwise, never ever that software... You can't do the software first... Some argue that it's stupid to do some hardware thing before the software supports that hardware thing...

As a developer I agree with you, but take a look at the AmigaOne X1000 and it's dual cores and 64 bits...

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Isn't JTAG a better tool for that? Not if you're a casual user or a beta tester! JTAG is good to have for hardware debugging. And a must for the designer. But for the rest of us we need a cheap terminal interface.

Honestly I never had the need to use a serial port just for debugging some software.

@thread

BTW: To all involved in this new design, Iggy, Ole-Egil, etcetera...
Remember to leave space on motherboard for Firmware Flash Rom and all related pins with enough ROM space for U-Boot Firmware (and future expansions) as actually U-Boot is the only firmware supported both by AmigaOS and MorphOS, and please leave a void pin for resetting it and connect it directly with J-Tag so it will be easy to upload a new version or re-install a previous one.

Last edited by Raffaele on 18-Nov-2015 at 11:50 AM.
Last edited by Raffaele on 18-Nov-2015 at 11:48 AM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

QorIQ boots from SD, so no flashrom needed. writing an SD is a whole lot easier than using JTAG.

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

QorIQ boots from SD

Well, that does appear to be the plan with Tabor.
Obviously, these processors don't have to be set up that way, but it is efficient and could make swapping out firmware easier.

As to 'sandboxing' legacy compatibility.
These CPUs offer a nice hypervisor, and the ability to run software on one or more cores separately.
Legacy compatibility should be able to be provided COMPLETELY intact by running the boxes separately.
And I can not think of anything that would prevent the two environments from interacting with each other (even to the point of have GUI linkage).

@olegil

I beg your pardon. That's not a matter of booting. Was not U-Boot necessary as a space to encode information about the license?

Am I wrong?

And btw is SD necessary? SD cards are slow and are well known to loose data easily. A standard HD or better a SSD Hard Disk are a solution more viable, reliable and have noteworthy more speed.

Last edited by Raffaele on 18-Nov-2015 at 04:31 PM.
Last edited by Raffaele on 18-Nov-2015 at 04:30 PM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

Quote:

Was not U-Boot necessary as a space to encode information about the license?

It was not.

Quote:

And btw is SD necessary? SD cards are slow and are well known to loose data easily. A standard HD or better a SSD Hard Disk are a solution more viable, reliable and have noteworthy more speed.

The idea is that you use the SD card to store the ROM, although having it as the boot partition or whatever could also be an option.

@Raffaele

Quote:

I beg your pardon. That's not a matter of booting. Was not U-Boot necessary as a space to encode information about the license?

I think that what Olegil meant was to put Uboot in an SD card, instead of a soldered or socketed flash chip as was done in teh Z1XE for example. You can't (easily) buy the old flash chip for the Z1XE anymore. That's inconvenient if you need to repalce it. To write Ubiit to that chip, you needed either a very expensive JTAG kit such as Abatron BDI2000/3000, or you needed to remove the chip and use something like Willem flash programmer. (I have a parallel port Willem kit, but parallel ports are hard to come by today) If Uboot is on an SD card, then pull it out and stick it into an SD reader USB adapter, or the slot built into your laptop. That's a bit more convenient than the A1XE chip. You can of course get embedded SD chips that are SMT but use same protocol as SD card, but you then lose the convenience of reprogramming. And Yes, I have used the Willem to salvagte a bricked A1XE board before, due to something bad happening during a flash update. The microSD way would/could have let that user do it himself for free.

And as I understand, there is some Hyperion/AmigaOS special sauce somewhere in the Uboot image to make OS4 work in the A1Xe/MicroA1 line, and I presume the same for the Sam boards and x1000 firmware. I don't know what or where, but I believe that a straight compile form uboot sources and burn to flash will lack that, and OS4 would not boot, but you could use Linux that way.

Last edited by billt on 18-Nov-2015 at 07:10 PM.

_________________
All glory to the Hypnotoad!

@iggy

Quote:

Legacy compatibility should be able to be provided COMPLETELY intact by running the boxes separately.

Granted that I only have a basic understanding of OS4.x SMP plans, which I believe had been described to essentially put a fill copy of OS on each CPU core (thread?) If I did understand that well enough, then you could put a 32bit OS copy on a core for 32bit legacy apps, and a full 64bit-native copy of the OS on another core for new 64bit-native software to run on. No 64bit segmenting required, go for "real/true" 64bit, and no breaking 32bit stuff. And yea, that's easy to say and I may not understand some real obstacle to that being doable, but it sounds cool...

_________________
All glory to the Hypnotoad!

@billt: this means that 32 and 64-bit apps run isolated from each other platform.

A sandboxed approach has the merit to offer at least some resources sharing between the sandbox (32-bit platform and its apps) and its host o.s. (64-bit o.s. & apps).

@billt

i don't know much about politics, I just know that booting UBoot off of an SD is inherently superior to booting it off a flash. Or rather, PUTTING UBoot ON an SD is FAR easier than putting it on a flash. Reading it out again is rather similar, actually.

I guess a jumper could select SD or flash, though. So booting from SD to write flash, then booting from flash to boot OS4. For OS4 to be secure it would make sense to put in some sort of I2C serial number OTP/ROM thingie. You get those in I2C eeproms anyway, which I had already put a socket for (because unfortunately you might need to reprogram the "reset configuration word", which instead of being a humongous amount of silly pins like in P series is a serial image from SD/flash/I2C etc in T series. Also, there's the matter of MAC address(es?)
This could do all of the above in one single chip, 8 pin socket.

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

@thread

For me it is OK! If you say that QoriQ series can boot directly a firmware from SD card instead than from a fix Rom chip so it seems better also for me.

But does it read firmware from a standard SD reader built on motherboard side of all common ports and connectors (because Qoriq has all circuitry to recognize a firmware inserted in SD), or does it require a secondary SD reader (dedicated only to Firmware) in a separate lane of bus?

I believed firmware needs to be accessed from time to time during common usage of computer, so it requires a SD reader of its own, separated from system SD reader...

Last edited by Raffaele on 19-Nov-2015 at 06:00 AM.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

Qoriq chips have an sdhc "reader" port built-in. Just need wires from there to the SD chip or slot.

_________________
All glory to the Hypnotoad!

@Raffaele

On the last board I designed we're running both UBoot and Linux from the same µSD card. It's partitioned as a normal harddrive, with UBoot occupying the first partition. The ROM inside the SoC is able to skip through unknown stuff until it sees the magic words of the UBoot partition, which it then loads.

I don't know how much OS4 accesses the Hyperion-magic in the bootflash, but nothing accesses UBoot after the OS has loaded.

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

@billt

Yes Bill, both OS4 and MorphOS could implement this type of dual kernal/OS environment to preserve a 100% compatible mode.

It is not that different than trying to run OS9 applications under OSX on a Mac.

Last edited by iggy on 19-Nov-2015 at 05:35 PM.