According the Amiga RC5 team the latest code cracker for Amigas does also run natively on AOS4.

But they state it doesn't use Altivec yet as ExecSG doesn't support it.
The same version for Morphos does have Altivec support.
(see the download page for more)


So won't we get the special speed of our G4?

_________________
A computerworld without MS products and Windows!
Connect your Amigas ...
...The Red ONE-A1XE G4 - A3000T- A3000 - A4000 - A2500- A1000 - A600 - CDTV - CD32...
and your PDAs and laptops ...
Psion 5mx Pro - Psion NetBook - Apple iPhone - MacBook Pro

@mbilla

MorphOS1.4 doesn't have Altivec support. It will come with MOS1.5

I guess that the final OS4 release will have altivec support enabled

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

ExecSG doesn't need Altivec support for the cracker to use it, there is altivec.resource in AOS4 wich should be enough for them to use it.

Cheers

_________________
Amon's digital home

@Amon_Re

Quote:

ExecSG doesn't need Altivec support for the cracker to use it, there is altivec.resource in AOS4 wich should be enough for them to use it

I beg to differ Firstly, altivec.resource does not yet exist. So, yes, that could be one solution, although AFAIK the full solution is for the ExecSG scheduler to save/restore the Altivec registers, where necessary, when switching between tasks. The only way for the Altivec cores to work in the distributed.net client on OS4-pre would be to do it a hacky way (and the problem would then be if some other app happens to touch Altivec, it'd invalidate the results in the distributed.net client). So, that's why the Altivec cores are not yet enabled in the client. As I've said elsewhere, Altivec versions will be released (it's simply a flick of a compiler switch, after all) when OS4 makes it possible.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@mbilla

Quote:

But they state it doesn't use Altivec yet as ExecSG doesn't support it.

Normally, to support AltiVec, you'd have to offer it to each process separately. This requires that the task scheduler exchanges the vector registers. The current scheduler doesn't do that, purely because of lack of time.

Quote:

So won't we get the special speed of our G4?

I think we listed AltiVec in the feature list, so you will get it. It's just not in the prerelease.

You must see that the prerelease is just that: A pre-release. If it weren't, it would be an end release. As it's not, not all features are implemented.

_________________
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

@Futaura

Quote:

Firstly, altivec.resource does not yet exist.

Not yet, yes.

Quote:

So, yes, that could be one solution, although AFAIK the full solution is for the ExecSG scheduler to save/restore the Altivec registers, where necessary, when switching between tasks.

That will be the case. The altivec.resource will just offer an arbitration for the streams. It will also allow you to "allocate" vector registers. As each vector register is 16 bytes, and there are 32 of them, this would make for 512 bytes of data to be saved at each context switch that is likely not to be used at all. Therefore, the allocation will be necessary (it will use the vrsave register to indicate which registers to save). I also assume that the compiler will do this autmatically.

_________________
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

A trick that is commonly used in x86 when saving the FPU state (all 128 bytes of it) is to hook up an interrupt that gets triggered when the FPU instructions are used and the task context has changed. At each context switch, a single CPU register is written to, which tells the CPU the context has changed, and if that task uses the FPU, the interrupt gets triggered and the interrupt handler swaps the FPU state (ie this happens on demand). It requires support in the CPU, but it means that if you have 50 processes and only two of them are using the FPU, you only need to move those 128 bytes 4 times instead of 100. Most programs don't use the FPU so it's an important optimization. Do PPC CPUs have a similar feature for the Altivec unit? I remember implementing it in a toy OS I wrote a few years back, and the context switching overhead went down noticeably.

@Futaura

Didn't know that it wasn't implemented yet, my mistake

_________________
Amon's digital home

If the RC5 client is the only Altivec using program that is running, the Altivec register data might not need to be stored in context switches, it might/could survive in tose registers. ?

Dirty hack, perhaps, but....

(yeah, dirty word: banging the HW)


Another thing...
When Altivec is taken in use is there a new danger that overclocked & passively cooled G4s start to have new heat problems when running RC5 24h/day ?
A lot of transistors that are now running idle would be put in heavy use.

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

@KimmoK

Short answer to overheating question:

Yes

_________________
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

Why did I just have a mental picture of a frazzled guy holding a fire extinguisher next to his computer?

@CodeSmith

Quote:

Do PPC CPUs have a similar feature for the Altivec unit? I remember implementing it in a toy OS I wrote a few years back, and the context switching overhead went down noticeably.

There's a better possibility on the PPC (of course ). The machine state register, which is swapped with each task, contains an FPU and an Altivec enable register. An optimization I plan to integreate soon(ish) is this: When these bits are 0, the CPU will generate an exception whenever you use an FPU or Altivec instruction, respectively. The idea is to keep these bits 0 when a task is created. As soon as it uses an FPU or Altivec instruction, the exception handler sets this bit.
This means that in the scheduler, these bits can be used as a hint: When they are not set, don't bother savinf FPU/Altivec state. This should bring down the context switch times some more (although they are already quite low).

This is one item on my ever growing, never shrinking Todo list

_________________
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

@KimmoK

Quote:

When Altivec is taken in use is there a new danger that overclocked & passively cooled G4s start to have new heat problems when running RC5 24h/day ?

Another item on my Todo list: Thermal management. The PPC can watch the temperature, and if it's too high, it can generate an interrupt. The handler can then use the instruction fetch throttling to slow down (and cool) the CPU...

_________________
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

Cool, sounds like a very similar idea then. On the 80486 (the CPU I wrote my toy OS for), the FPU and MMX use the same registers, so it's a pain to write 3D games with MMX support (you have to switch into and out of MMX mode, which takes a few dozen cycles), but it made my life as an OS writer very simple

Hmmm, that project brings back a few memories. I should get back into hardware coding, that was fun (except where intel's docs were, um, "not entirely complete" ).

@EntilZha

Actually, I just realized that you can make use of that PPC register to implement the exact same optimization I used. Basically, you do this:

1. There is a pointer, which keeps track of the last task that used Altivec
2. When any task gets the CPU, you clear that status bit (so an exception will be triggered if the task uses Altivec). You always do this, for all tasks.
3. If the exception gets triggered, you copy the current Altivec state to the task info block that's being pointed at by the pointer mentioned in 1, then you retrieve the Altivec state for the current task and set the pointer to point to the task info block of the current task. You also enable Altivec for the current task, to prevent more exceptions during this timeslice.

That's it - you only ever need to copy those 512 bytes when you need to, so if eg a task uses Altivec once at the beginning and never uses it again you won't need to keep on saving and restoring its altivec state at every context switch (if a task needs to use Altivec, it will trigger the trap that causes the copying of state to happen - if the task does not use altivec during this timeslice, there's no trap, there's no copy). Plus the saving and restoring happen outside of the regular preemption task switch, so your multitasking will be a little bit smoother. I don't know if it's because I didn't understand your explanation, but this sounds a bit more efficient than the technique you described - that sounded like the trap was only a hint that saving/restorig of state needs to start happening for a given task (and then will continue until the task ends), while this is using the trap in a similar way that the MMU is used to implement virtual memory, only to implement lazy state save/restore instead. You can do the same thing for FPU state, using the other status register bit you talked about and a different task pointer.

Quote:

EntilZha wrote: Another item on my Todo list: Thermal management. The PPC can watch the temperature, and if it's too high, it can generate an interrupt. The handler can then use the instruction fetch throttling to slow down (and cool) the CPU...

This is becoming a heroic feat of OS development

_________________

Hi CodeSmith,

Could the Altivec keep computing, if the next "task" doesn't use it? Or something to that effect, anyway.


AmigaOne! AOS4.0! Keep on rocking "Hans and Frans"!!!! (Oooopps, that's SNL. )

@EntilZha

Quote:

EntilZha wrote: This is one item on my ever growing, never shrinking Todo list

Soon you will have to write bugzilla enhancement requests to yourself

I really like the idea of minimizing the taskswitching overhead by not bothering saving register sets from units that haven't (yet) been used.

@Atheist

Well, you can't really keep the altivec keep running in that sense after a task switch since the code that was running on it no longer has the CPU. Whatever instruction it was executing during the switch should complete (due to parallelism), but once the switch is made, the code that was using the altivec is no longer being used.

_________________
Doing stupid things for fun...

@Karlos

Indeed. It isn't a co-processor in the sense that you can set up a copper-list. It's only able to do vector instructions, it would have to have its own load/store unit and a branch system to be able to do something like that. Which is what one had in the copper on the classic Amiga

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

@CodeSmith

Quote:

1. There is a pointer, which keeps track of the last task that used Altivec 2. When any task gets the CPU, you clear that status bit (so an exception will be triggered if the task uses Altivec). You always do this, for all tasks. 3. If the exception gets triggered, you copy the current Altivec state to the task info block that's being pointed at by the pointer mentioned in 1, then you retrieve the Altivec state for the current task and set the pointer to point to the task info block of the current task. You also enable Altivec for the current task, to prevent more exceptions during this timeslice.

I don't think it's necesary to do it like this. The simples method is to use the enabled bit in the machine state (which is always switched with the task): When a task is launched (i.e. is becoming the active task) that has the bit set, the vector registers are restored (according to vrsave). When a task is switched, and the Altivec bit is set, the vector registers are saved. If the next ready task does not have the Altivec bit set, the vector registers are not restored. That way, only tasks that actually use Altivec will have those registers restored/saved, and non-altivec tasks don't.

_________________
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