@EntilZha

Quote:

Register renaming is very common on modern CPUs. All PowerPC implement this as well.

Note that I wasn?t specific in relation specific CPU arch...

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer



No offense intended, but the thing is, you do appear to be AW.net's resident "Mr. x86" - whether you intend to or not I think people just automatically assume you mean x86 these days unless you explicitly state otherwise

_________________
Doing stupid things for fun...

@CodeSmith

Thx for the long reply. You are right. I missinterpretted your first post. Sorry.

re

Treke

@EntilZha
Quote:

AFAIK, the thermal sensors on newr CPUs (750FX, 7455) is pretty reliable. At least it can give an indication on the temperature...

I don't have any really current update, but the Mot 7455 errata sheet was last updated in December, still has the TAU problem listed as #3 with no qualifiers for PVRs affected.
Quote:

Description: The (TAU) on the MPC7450 and MPC7455 reports temperatuures between 35 and 55 degrees lower than expected. [...] If a trip temperature is programmed into the sensor's control registers, the output interrupt is never received, even if temperatures exceed the expected setpoint by up to 55 degrees (even after calibration). [...] Projected Solution: None. The TAU is not supported on the MPC7455.

Linux still explicitly disables thermal monitoring for the 745x CPUs.

For the 750FX, the IBM errata only says that the TAU output is not reliable without calibration.

Scott Woodall

@Treke

Hey, no sweat. I was bored and long descriptions of technical stuff just seem to flow out of me when I'm like that

@swoodall

Cool, that's one less thing for EntilZha to do then

@EntilZha

I have absolutely no idea what you guys talking about!

Hyperion U rool!!

_________________
If you play a Linux DVD backwards you can clearly see a cool place with penguins. If you play it forwards, it will install the greatest operating system available for your PC computer!

@Karlos

Anyone have spare x86s that are not needed by anyone like 486s? Well heres a fun thing to do with them! Go out and buy an axe and a blow torch and see what damage you can do!

_________________
If you play a Linux DVD backwards you can clearly see a cool place with penguins. If you play it forwards, it will install the greatest operating system available for your PC computer!

@Karlos

Quote:

Is there a similar mechanism for the IU / FPU register set? It seems a very obvious optimisation in hindsight

Unfortunately not. For the vector registers, this obviously made sense because of the size of the registers... although in the 745x/744x, it probably doesn't matter anymore since they have an internal 256 bit data bus, so the store has very low latency...

_________________
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

@Hammer

Quote:

Note that I wasn?t specific in relation specific CPU arch...

Ah, ok... You quoted something about MMX/FPU switching, so I was assuming you specifically aimed at x86...

_________________
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

@swoodall

Argh, too bad...

Well, one less item on the Todo list, although I really liked to have that...

_________________
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

If you're looking for a replacement project, how about this: mark all heap and stack pages as non-executable and all code pages as read-only. That will make worms and viruses a lot harder to write. Unless there are serious compatibility problems (I don't consider self-modifying code to be one of those), I think that's a lot more useful than thermal monitoring; you can sell a lot more copies of AmigaOS by saying that it's very hard to exploit buffer overruns than you can by saying that it's overclocker-friendly

@CodeSmith

Quote:

If you're looking for a replacement project, how about this: mark all heap and stack pages as non-executable and all code pages as read-only. That will make worms and viruses a lot harder to write. Unless there are serious compatibility problems (I don't consider self-modifying code to be one of those), I think that's a lot more useful than thermal monitoring; you can sell a lot more copies of AmigaOS by saying that it's very hard to exploit buffer overruns than you can by saying that it's overclocker-friendly

You're too late, that's already implemented . Memory containing PPC code is the only memory that is executable, and it's automatically write protected when a binary is loaded.

The execute permission thing is actually necessary since this is used to quickly determine if an address contains PPC code or not. Hooks and interrupt handlers use this to determin whether to jump or emulate...

_________________
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

Hi EntilZha

Quote:

EntilZha wrote: You're too late, that's already implemented . Memory containing PPC code is the only memory that is executable, and it's automatically write protected when a binary is loaded. The execute permission thing is actually necessary since this is used to quickly determine if an address contains PPC code or not. Hooks and interrupt handlers use this to determin whether to jump or emulate...

There are hostile forces at work. The enemy is at the gates.

The less we know, the better?


AmigaOne! AOS4.0! Shadows complement the light.

@EntilZha

I agree it is a shame they didn't get the thermal sensor on the G4 working any better. I think that on-"board" sensors will keep becoming more important, especially as formfactors shrink and clockspeeds increase, smaller imbedded applications, etc.

How about this as an alternative: instead of just CPU temp monitoring in the OS, create an open sensor.device API. Allow device drivers/apps to bind in sensors as different device numbers with a description, values (calibrated and not), calibration offsets, etc. Then you can implement and register the CPU(s) TAU, and maybe the VIA686 temperature and fanspeed sensors (those can be very useful). Other devices like graphics cards with fanspeed sensors of their own, can register their own devices -- maybe those drive-bay fan controllers too, etc. Then user applications can interface with sensor.device unit X to monitor the CPU temp, a little 20-line dockie can graph sensor.device unit Y to show case temp or fan speeds. Maybe the device model isn't perfect, but I think something along those lines would be a great addition to the OS. (I have been doing too much SNMP monitoring lately, I can tell...)

Hey, look ^^^. There's a perfectly good idea sitting there in the public domain for anyone in the world to implement...

Scott Woodall

@Atheist

Quote:

The less we know, the better?

Allow me to be confused.. What's that supposed to mean ?

_________________
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

@swoodall

Interesting idea...

_________________
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

I think he means "Keep mum cos careless talk costs lives".... M$ may be reading this thread and pinch ideas... Amiparanoia me thinks...

@ Thread

I have a plan for thermal management - its the perfect solution, it may double a chips speed and keep it super cooled at the same time!

I woulnd't want M$ to find out as they could really do with such technology .. So this information that I am about to tell you must go no further than this thread.


No need for thermal compound paste, heat sinks or fans - just use salty custard.

Take a pint of custord - it has to be boiling hot. To this mix, add 1 Lb of salt. Then - making sure that your sysetem is turned on, smear this salty custard mix all over your motherboard. Initially the board will get very hot - but in time it will cool down

If you do attempt this method - it comes with no guarantees. If you do wish to try it out, I suggest you use an x86 box running any of the windows operating systems first.





[DISCLAIMER: If you do smear a computer in salty custarc - you're an idiot. Dont do it. It could lead to loss of life etc.. and bugger up your computer]

@EntilZha

Quote:

@swoodall Interesting idea...

Indeed. That could even be expanded into something like the linux /proc filesystem or Windows performance counters. A single, expandable, universal way to query the system for all sorts of info. Hmmm

@EntilZha

Quote:

You're too late, that's already implemented . Memory containing PPC code is the only memory that is executable, and it's automatically write protected when a binary is loaded. The execute permission thing is actually necessary since this is used to quickly determine if an address contains PPC code or not. Hooks and interrupt handlers use this to determin whether to jump or emulate...

Nice! How do you determine if a particular memory area contains "legit" 68K code? Specifically, if I overrun a buffer and inject some 68K code into the stack (or the heap, I guess), will the 68K emulator run that code?