@amipal

Quote:

amipal wrote: @Bobsonsirjonny Quote: I just want an OS I can use, and does what it says on the tin 2 Days dude - then you get Beer I think WE'LL be buying the drinks for EntilZha and Co.!!!

Exactly

Quote:

Bobsonsirjonny wrote: Exactly

Hi Bobsonsirjonny,

Exactly!


Also, exactly.

Well, I mean that pudding thing. Well, I mean the revelations of the innards of AOS4.0 being revealed that convey more opportunity for the mischevious to mischieve. *

Makes me nervous.


AmigaOne! AOS4.0! Some mysteries should remain unresolved.

Just to let you know: OS4 supports Altivec since today (I had nothing else to do today )

I went for the "simple" approach: When a task starts, it's launched with Altivec disabled, thus no vector registers are stored during context switch. The first altive instruction then generates an exception, and the enable bit is set. From then on, the task saves/restores Altivec context whenever it is scheduled. vrsave is used to keep track of the registers.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@EntilZha
This is a news item Mr Frieden !!

btw ..

WELL DONE

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

@EntilZha

_________________
Everything is proceeding as I have foreseen

Some people are like slinkies. Not really good for anything but they bring a smile to your face when pushed down the stairs.

@EntilZha

Quote:

EntilZha wrote: Just to let you know: OS4 supports Altivec since today (I had nothing else to do today ) I went for the "simple" approach: When a task starts, it's launched with Altivec disabled, thus no vector registers are stored during context switch. The first altive instruction then generates an exception, and the enable bit is set. From then on, the task saves/restores Altivec context whenever it is scheduled. vrsave is used to keep track of the registers.

That's great news. It's really great when you have nothing else to do. I doubt that happens very often.

Anyway, by the time that becomes available in the the first update to OS4, maybe I'll have figured out how to put it to use. As it is, I know almost nothing about Altivec.

Dave M.

@EntilZha

That was really breaking news

_________________
Site admins are people too..pooff!

@EntilZha

bloody great news indeed .

@EntilZha

Quote:

Just to let you know: OS4 supports Altivec since today (I had nothing else to do today ) I went for the "simple" approach: When a task starts, it's launched with Altivec disabled, thus no vector registers are stored during context switch. The first altive instruction then generates an exception, and the enable bit is set. From then on, the task saves/restores Altivec context whenever it is scheduled. vrsave is used to keep track of the registers.

Congrats.
If bits in vrsave are zero, then no save is done, even if the task is already using Altivec ? Did I get it right ?

@Bobsonsirjonny

Re C Programming

Leicester University has decent online tutorials
here.
Should be enough to get you started.

-john

@Treke

Quote:

If bits in vrsave are zero, then no save is done, even if the task is already using Altivec ? Did I get it right ?

Yes. Usually, gcc clears vrsave when leaving a function that uses altivec, so task scheduler overhead is minimal.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

Will there be a trap library for processors without altivec? Or will using binaries with altivec code simply crash on processors without it?

/Björn

@Orgin

Quote:

Will there be a trap library for processors without altivec? Or will using binaries with altivec code simply crash on processors without it?

Writing an "emulation" for altivec is a big task, and I don't think we'll be going through this. There are functions in the Exec API to test for the presence of Altivec, and applications are required to check this and not execute altivec instructions if not present.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Orgin

I'd say it might make sense to check what sort of CPU (check == with the provided API by the AltiVec-using program) is in an Amiga before using Altivec features. If not replacement non-Altivec-functions should be used by the program, without needed user-interaction, IMHO.

Steffen

@Rogue

Okey cool. Thanks.

I assume that it would technically be possible for a third party to supply such emulation though? (If looking at it technically and not whether there would be a need for it.)

/Björn

@Orgin

Quote:

I assume that it would technically be possible for a third party to supply such emulation though? (If looking at it technically and not whether there would be a need for it.)

Yes. It would cause a "program exception", and an emulation would need to check for the instruction that caused this, and emulate its meaning.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

AFAIR, the Altivec.resource isn't done yet, it is scheduled only for final version ?

Btw the solution suggested by codesmith in 2nd reply from top looks more effective (if the exception handling is fast), but it is harder to implement. A bit speculative in speedup gain, but maybe worth a measure.

Don't take it as a nitpicking pls, (and on the end of the thread ! ) the Altivec support is realy a great thing.

re

Treke

@Treke

Quote:

AFAIR, the Altivec.resource isn't done yet, it is scheduled only for final version ?

Altivec resource was meant as an arbitration/detection method for Altivec. It has been more or less superceeded by Exec's API function GetCPUInfo.

Quote:

Btw the solution suggested by codesmith in 2nd reply from top looks more effective (if the exception handling is fast), but it is harder to implement. A bit speculative in speedup gain, but maybe worth a measure.

The problem here would be to anticipate when a task is going to use the altivec unit or not. That is, if Task A is preempted then you don't know if task B is going to use altivec or not.

The proposed method of storing the altivec registers in the interrupt is a bit problematic - the vector for the Altivec Unavailable interrupt is rather small, and the PowerPC does not save anything onto the stack upon an exception, so you would need to store the current CPU context before you can do any sensible work.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Treke

Quote:

AFAIR, the Altivec.resource isn't done yet, it is scheduled only for final version ?

It won't be necessary. Initially, it was meant to "allocate" vetor registers, but since gcc generates the necessary vrsave code itself, and without the use of the system, it wasn't needed anymore. Same goes for streams.

To detect if there is an Altivec unit, you can use a new exec function ("GetCPUInfo") that will tell you if there is one or not.

Quote:

Btw the solution suggested by codesmith in 2nd reply from top looks more effective (if the exception handling is fast), but it is harder to implement. A bit speculative in speedup gain, but maybe worth a measure

This is probably more efficient (I haven't looked at this in detail yet), but since the scheduler will be replaced for 4.1, the more sophistcated algorithm can come in later. For now, the vrsave and msr marking will make sure that the overhead is kept at a minimum. The important point is that it works And it's transparent to the application code, anyway, so later changes will not affect the applications...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment