Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
76 user(s) are online (67 user(s) are browsing Forums)

Members: 0
Guests: 76

more...

Support us!

Headlines




« 1 (2) 3 4 5 ... 8 »


Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854
a lot of work.. I am curious to know if the speed up of the JIT for UAE will be like the JIT under Amiga OS 4 (Petunia)

Btw, thanks for the effort and good work!

   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854

   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854
another update and this time a big step forward!!

http://euaejit.blogspot.it/2013/05/on ... r-mankind-giant-leap.html

   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2006/11/17 17:13
From Belgium
Posts: 236
Pfff and brrr.

_________________
A1G3-SE + OS4.1 u1 iso (x2)
   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854

   Report Go to top

Re: Big E-UAE JIT blog
Quite a regular
Joined:
2008/4/10 14:57
From Northern Ireland
Posts: 971
Thanks. All progress is welcome!

_________________
AmigaOne X1000.
Radeon R9 270X

http://www.tinylife.org.uk/
   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2006/11/17 17:13
From Belgium
Posts: 236

_________________
A1G3-SE + OS4.1 u1 iso (x2)
   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854
Nice! :)

   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854
Another update! we are getting closer! :)

http://euaejit.blogspot.it/

   Report Go to top

Re: Big E-UAE JIT blog
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4030
Cool, i hope this project will reach its goals.

Not that i do very much with eUAE, but id love to have an updated emulator for some of my favourite games...the current emulation just doesnt cut it.

Way to go Rachy

...and thanks to all for the testing

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/11/24 17:54
From Sanremo
Posts: 1854
82% completed, it is almost done! I think that for the end of this year the project will be finished!, fingers crossed! :)

   Report Go to top

Re: Big E-UAE JIT blog
Just can't stay away
Joined:
2006/12/1 18:01
From Copenhagen, Denmark
Posts: 1229
@nubechecorre

Don't forget the 90/10 rule: 90% of the time is spent on the last 10% of the project .

(Let's hope it doesn't hold true in this case.)

Best regards,

Niels

   Report Go to top

Re: Big E-UAE JIT blog
Not too shy to talk
Joined:
2006/12/1 23:50
From Skærbæk. Denmark
Posts: 266
I have always wondered why JIT for UAE is only possible for CPU with cache..

why is a500 with a 68000 not possible with the current system?

_________________
“The best thing about a boolean is even if you are wrong, you are only off by a bit.”
   Report Go to top

Re: Big E-UAE JIT blog
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2941
@rwo

Because code is loaded in and out of memory all the time, some programs start some are terminated, and this happens the OS flushes the CPU cache.

If the JIT compiler does not know, it will store the old code in JIT cache, wrong code will be executed and every thing will crash.

You might be able to work around it by patching the OS, but then its a OS emulator not a hardware emulator.

Workbench 2.04 was first version of the OS that supported CPU cache, so its lowest OS version supported by JIT.

Flushing the cache on a branch or trying to work around the issue will result in JIT cache being flushed too often and so the code generator is executed too often for JIT compiler to be effective.


Decrypting routines used too prevent piracy and preventing hackers to understand track-loader, self modifying code, compressed executable is also a big issue, its was not uncommon to use this tricks on Amiga500, and whit out knowing when code is changed, it be a disaster.


Edited by LiveForIt on 2013/10/4 0:00:25
Edited by LiveForIt on 2013/10/4 0:06:47
Edited by LiveForIt on 2013/10/4 0:08:00
_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2008/12/3 13:26
Posts: 131
wwhat about the cpu from the amiga 500+(plus) didnt that have the chace thing

   Report Go to top

Re: Big E-UAE JIT blog
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2941
@retro

Amiga 500 Plus has the same CPU as the normal Amiga 500, there where littel difference between this two models.

http://en.wikipedia.org/wiki/Amiga_500
http://en.wikipedia.org/wiki/Amiga_500_Plus

But that is not the point, the point is that cache is a software hardware thing, programmers should use the CacheClearU() or CacheClearE() routines, but this did not exist in kickstart1.3.

Older kickstart do not have the routines, so you can can clear the cache, besides there are no games for Amiga500 that know that they needed to call CacheClearU() or CacheClearE() routines, and this is the main problem, the games where never designed to run on new CPU models, anyway forward compatibility is impossible to archive, because you do not know what is coming, backward compatibility is how ever easier, and so newer CPU can disable CPU cache for backward compatibility .

And because JIT depends on Cache to work, its impossible to get to work this way, unless you spend hours patching the software, but way do that when you can run whdload version that is already patched.

_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2013/10/2 5:12
From Adelaide, Australia
Posts: 20
@nubechecorre

Great stuff - excellent to hear things are moving along. I am really looking forward to this being available!

Catcha,
Epsilon

   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2007/4/1 10:16
Posts: 50
@LiveForIt

Self modifying code may be a pain in the you-know-where for a JIT/recompiler, but you still need to handle it to some extent when emulating a CPU with a cache. It's quite simple to design your code in such a way that the cache is automatically flushed as need, without using any of the cache control opcodes. (Silly example for the 68020: Store 256 bytes of NOPs somewhere and jump through them to flush the cache.) There is also a lot of older software, designed for the A500, which runs just fine on an A1200 with the cache enabled.

By implementing some simple cash coherency, only forward modifications within a compiled block will fail to work. This is the approach used by FPSE for example, it simply ignores the special register setup and writes which are normally used to flush the cache, and instead handles the flushing itself as needed, i.e. when a compiled block is modified.

   Report Go to top

Re: Big E-UAE JIT blog
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2941
@AmiDog


Quote:
It's quite simple to design your code in such a way that the cache is automatically flushed as need, without using any of the cache control opcodes. (Silly example for the 68020: Store 256 bytes of NOPs somewhere and jump through them to flush the cache.)


You mean whit the intent to write a program or games that will work whit and whit out CPU cache, of course no old program will have bunch of NOPs in it to handle this.

You will need to inject it into the code, or maybe you were thinking about the consequence of this kind of trick, I can see how that might be problem if the JIT compiler did not handled it.
Quote:
designed for the A500, which runs just fine on an A1200 with the cache enabled.


Is not CPU cache default off, until its enabled by setpatch, I think I remember reading something like that.

So booting a Amiga500 floppy game on A1200 should run the program code whit out CPU cache, unless the game enables it?

Anyway I remember there where some options for more compatible setting in the 3.0 Kickstart rom, don't remember what it was for.
Quote:
This is the approach used by FPSE for example, it simply ignores the special register setup and writes which are normally used to flush the cache


You mean by identifying code signatures specific instructions streams?
Yes if you can identify the decryption routines and cruncher routines, it might make more things work, but that must be huge task.
Quote:
when a compiled block is modified.

Well then you need to check if address written to is a code block, I guess you can write protect code blocks whit the MMU to trigger a interrupt when this happens, but is there not a problem whit Memory block boundaries.

Or else you will need to compare the addresses whit memory blocks, that might be slow and give big penalty for the write operations.

_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: Big E-UAE JIT blog
Just popping in
Joined:
2007/4/1 10:16
Posts: 50
@LiveForIt

Yes, exactly, if you code something for a specific CPU, you can sometimes take advantage of the caches being automatically flushed due to, for example, running a large piece of unrolled code. That will save you the hassle of actually doing the flushing programatically. It might even be faster, depending on how the actual cache flush has to be performed.

I have always assumed that the CPU cache is on by default since there's an option in the early startup menu to disable it. But perhaps that option only affects SetPatch somehow, I really don't know.

Yes, FPSE will, for each write, check if that write does modify a compiled block or not. That might seem very slow, but it is only a single table lookup.

   Report Go to top


« 1 (2) 3 4 5 ... 8 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project