@pavlor

Quote:

pavlor wrote: @cdimauro Quote: A 68K platform implemented as FPGA can have fully control such kind of accesses, so it's pretty easy to implement an SMP system. With Amiga-like OS? We'll see.

Even with the original Amiga o.s., but with some patches to dispatch tasks to the available cores.

But I think that AROS/68K can be the only realistic option for such systems, since it's currently developed.

@cdimauro

Quote:

PowerPC CPUs do NOT support locking memory accesses at the byte level (only at the word/32-bit level). The Amiga o.s., OS4 included, as some sensible structures which manage task and interrupts, and they are... byte-sized.

And where is the problem here?

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun

Quote:

BigGun wrote: @cdimauro Quote: PowerPC CPUs do NOT support locking memory accesses at the byte level (only at the word/32-bit level). The Amiga o.s., OS4 included, as some sensible structures which manage task and interrupts, and they are... byte-sized. And where is the problem here?

You cannot lock a single byte for the byte increment or decrement operation of the counters used by the Amiga o.s..

@BigGun

when will be ready one with fpu and mmu i will thake for my A500+

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@cdimauro

Quote:

You cannot lock a single byte for the byte increment or decrement operation of the counters used by the Amiga o.s..

Locking single byte is no problem on PowerPC.
You look a LONG - which technically will lock the whole cacheline.
You then load the LONG and update your Byte.
And then store conditionally the LONG back.

This works fine....

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun

68K is a lot simpler to code this.
You need for an atomic increment only 1 instruction on 68k - but a whole routine with loops and checks and sync and whatnot on POWER.

So its more complex to code and their is risk to make a mistake.

What is impossible to do on POWER is working with misaligned atomics which span 2 cache lines. This can not be emulated with POWER instructions at all.

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun: right, but you cannot lock every byte access, or performance will go down a lot.

Anyway, the point is that are existing applications which have such byte accesses, but you want to lock only the locations which are related to the Amiga o.s. counters.

How can you do it with the PowerPC ISA? Is there any mechanism to monitor & control only such locations? I mean, without hurting so much the performance.

@BigGun

I'm waiting for Vampire 500 to be installed in my CDTV

@cdimauro

Quote:

@BigGun: right, but you cannot lock every byte access, or performance will go down a lot. Anyway, the point is that are existing applications which have such byte accesses, but you want to lock only the locations which are related to the Amiga o.s. counters. How can you do it with the PowerPC ISA? Is there any mechanism to monitor & control only such locations? I mean, without hurting so much the performance.

To prevent any misunderstanding:
My understanding is you want to do an atomic update to a Byte?
Or something like a TAS?

On 68k this is pretty simple as from a TASK /THREAD perspective every instruction is atomic.

On POWER you need at least 3 instructions for an update
LOAD
ADD
STORE

So on POWER there is by design nothing atomic here.


What you do on POWER is an

LWARX to allocate the 4 byte the value is in (effectively it will snoop the whole cache line)
then you do your update instructions
This could be 1 instruction for a simple add.
But could also be more if you want to only update parts of the long - then you need to AND with a MASK
then you to a STORE_RESERVATION_CONDITIONAL of the value
This store will do update the value if no one else did touch the cache line
If someone else did touch it- then the store will do nothing but set a flag
Then you do a BRANCH on the flag which will jump up and retry if there was a problem
And you need some SYNC instructions. Depending on which scenario you are in you some LWSYNC at least.

This is how you do this on Power..
A bit more complex than on 68k - but it works
But you are toast if the atomic values are misaligned.

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun: I know it, but it's not what I mean.

The problem is trapping/controlling accesses/updates of the 2 counters that are used by the Amiga o.s. for the task and interrupts counters. It should be made for existing PowerPC or 68K applications (which are emulated by PowerPC; and emulation can be changed, I know, but it should be kept fast).

So, suppose that you have an existing application that whats to disable the multitasking increasing the task counter, and that for doing that it directly accesses such ExecBase field in some part of the code. How can you trap/control that access in a multicore system to implement SMP (without losing backward compatibility, of course, with the already written applications)?

I hope that it's clear now.

@BigGun

Quote:

Apollo also has an MMU.

Oh really? That makes it tons more interesting. Will you assure that operating systems requiring the MMU will work without modifications? I think of the possibility to run f.ex. old NeXTStep on it, or will it be a "new" MMU that will require dedicated support for Linux and the BSDs to work?

I'm very interested in new hardware for Linux/m68k, and I know a few BSD developers also want new fast and memory rich m68k hardware to build software packages on.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Oh really? That makes it tons more interesting. Will you assure that operating systems requiring the MMU will work without modifications?

No, Of course not.

This is not "the 68k MMU". The different 68K have incompatible MMUs.
Each 68k MMU was a development of "its time" and tried to change / improve the concept of the MMU. And this makes sense as over the years the knowledge and situations change.

Of course we want again to improve this for our users and not stay bug compatible and limited to an old design

As the developer of the most used MMU software is part of our team - this is a sensible concept IMHO.


Quote:

I'm very interested in new hardware for Linux/m68k, and I know a few BSD developers also want new fast and memory rich m68k hardware to build software packages on.

I can understand that someone want to use an 600 Mhz 68020 to run AMIGA OS
I'm puzzled why someone would want to use a 600 Mhz 68K or a 800 MHZ PowerPC to run Linux - today.

Also if you talk to an Linux Kernel Developer about the 68K MMU - their first answer would be to add new features to it

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun

Is there any kind of official documentation for the core?
It seems that (at least) the public part of the Apollo forum doesn't have any in depth explanation of some design decisions, like the encoding of the extra registers (E0..E7) and the MMU.

Great work BTW! :)

@BigGun

Quote:

I can understand that someone want to use an 600 Mhz 68020 to run AMIGA OS I'm puzzled why someone would want to use a 600 Mhz 68K or a 800 MHZ PowerPC to run Linux - today.

Well, why not?
It works great and we've been doing it for more than 20 years. A lot of code is shared with uCLinux that is typically used for 68SEC000 projects and it also helps keeping the GNU toolchain m68k capable. Keeping Linux and *BSD alive on m68k is not so much work anyways.

Many people are puzzled as to why we bother with AmigaOS still.

Quote:

Also if you talk to an Linux Kernel Developer about the 68K MMU - their first answer would be to add new features to it

So have you talked to Linux/m68k kernel developers lately?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@BigGun

Quote:

I'm puzzled why someone would want to use a 600 Mhz 68K or a 800 MHZ PowerPC to run Linux - today.

Bit of a double standard don't you think ?

We Amigans of all people are offended when they say that to us, how would you respond if i said this to you ?

Quote:

I'm puzzled why someone would want to use a 600 Mhz 68K or a 800 MHZ PowerPC to run AmigaOS - today.

Why not just say you are just not interested ?

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@asymetrix

Quote:

We Amigans of all people are offended when they say that to us, how would you respond if i said this to you ?

gunnar is perfectly reasonable on this. you have no choice to run amiga natively other than on a 68k compatible cpu. for linux you have got all kinds of hardware better supported and faster than 68k or ppc. certainly there are people who would like to do that, but that depends on actual interest, cooperation and the good will and capabilities and of the project team

@megol

Quote:

Is there any kind of official documentation for the core? It seems that (at least) the public part of the Apollo forum doesn't have any in depth explanation of some design decisions, like the encoding of the extra registers (E0..E7) and the MMU. Great work BTW! :)

Documentation will come when core gets released.
Right now our focus is on implementation and testing ...

New Register is for example A8 which can be used as base-pointer.

_________________
APOLLO the new 68K : www.apollo-core.com

@wawa

It only takes one person with sufficient interest, and interestingly enough people seem to be interested in things like that.

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

It only takes one person with sufficient interest, and interestingly enough people seem to be interested in things like that.

Of course but design, develop and test a complete new accelerator card takes a lot of time and cost some money - not sure if a single person want to pay this amount....

I have nearly every AMIGA model from A1000 to CD32 to be able to test our cards and verify the bus controllers etc.

Maybe for those people upgrading from their system to our new stand alone system would make sense?

_________________
APOLLO the new 68K : www.apollo-core.com

@olegil

here you go, from the horses mouth.