Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
45 user(s) are online (36 user(s) are browsing Forums)

Members: 2
Guests: 43

davebraco, cloverskull, more...

Support us!

Headlines

 
  Register To Post  

« 1 2 3 (4) 5 6 7 8 »
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@Deniil Quote:
We have been living without JIT since the beginning of time, so let's not waste time on that to begin with. I think I heard someone (Fab?) was working on the JIT engine at some point..?

It was NOT Fab, but (apparently) "bigfoot":
https://morph.zone/modules/newbb_plus/ ... p?topic_id=11523&forum=32

Some interesting comments (see linked thread for full info) :
pampers wrote:
Quote:
Another bounty which is still on hold is JIT JS for Oddysey. There was some progress at some stage ... but bounty was never completed.

I was talking with bigfoot and he came back to developing it but he cannot promise any time frame. I'd say bigfoot will speak for himself in this topic soon.


bigfoot wrote:
Quote:
I'm not sure there's really that much to say. When I took the bounty, I made an estimate for how much time it would take to complete the JIT implementation for PPC32. In fact, I finished that task a bit faster than I had originally estimated. What I didn't realise was just how broken Webkit was internally, and how much of a problem it would pose.

The problem is that the JIT engine internally expects a little endian memory layout. This is different from other endian problems in that the JIT engine itself isn't what isn't endian safe, it's the code that the JIT engine generates that isn't.

Webkit's Javascript engine internally treats all Javascript values as 64 bit floating point values. This not only includes actual floating point values, but also integers, strings, objects and so on. This means that every value that the JIT-generated code uses is a 64 bit value, even on 32 bit architectures. How this works is that there are certain bit encodings of floating point values that are illegal, and which will never be the result of a normal floating point arithmetic operation. These encodings are then used to indicate if a value is actually something else than a floating point value.

Now, the problem is that we're on a 32 bit CPU, so the integer part of the CPU, which is what is used for doing these tests, and for passing data around, can only load 32 bits at a time. The JIT engine then generates code that expects the upper 32 bits of the 64 bit floating point value to be located at address + 4. This assumption is made roughly every 20-30 lines over tens of thousands of lines of code. Furthermore, it expects 64 bit values to be passed and returned in 2 32 bit registers, which is perfectly normal, but it of course expects the order of this register pair to be swapped, while at the same time expecting 32 bit return values to reside in the register that also holds the lower 32 bits of a 64 bit return value. This assumption is made for every single interaction between JIT-generated Javascript code and the compiled Odyssey binary. Every time your Javascript code calls for example Math.Floor(), this assumption is made in the JIT-generated code.

So what's the status of all this? I found and fixed probably 99% of all of the above issues. Yet at least two issues remain that are rather tricky to track down, and those two (or more) issues cause most large websites to fail, because one of the pieces of Javascript tha triggers one of the remaining issue is a Javascript framework that's used by just about everyone.

So, as Pampers mentioned, I still want to finish this, but with the amount of time I ended up spending on fixing endian issues in the JIT engine, I overshot my initial time estimate by at least a factor of 5, and I had to focus on other things to get an income. Thus, I'm still (obviously very slowly) working on this, but I (also obviously) no longer expect to get paid for this work, and thus if anyone wants their money back or wants to assign their money to another project, then of course it is no problem.



P.S. I was under the impression (which could be wrong) that the Javascript JIT could end-up being closed-source MorphOS-only, at least initially. I am unclear whether the author would be willing for an OS4 port, and whether that would require another bounty... HOWEVER, it seems it may be open source?:
https://morph.zone/modules/newbb_plus/ ... sortorder=0&showonepost=1


Edited by ChrisH on 2017/4/3 21:24:22
Edited by ChrisH on 2017/4/3 21:27:05
Author of the PortablE programming language.
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@Deniil
Quote:

One question: Is it the JS JIT that has endian issues, or the plain interpreter?

We have been living without JIT since the beginning of time, so let's not waste time on that to begin with. I think I heard someone (Fab?) was working on the JIT engine at some point..?


Plain one. ChrisH already point out on the JIT one on which bigfoot work, but for us will be fine even have crash-free plain one, at least in the same state as we have in the webkit core we have for 1.23 version of odyssey.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@kas1e

Yeah the story is well know, let's hope fab will back at some point restarting from the current 1.25 and adapting the recent JS changes to PPC
By the way how about try porting the old 1.24?

Not a big evolution compared to what we have already, but better than nothing

Go to top
Re: We so need an updated browser!
Quite a regular
Quite a regular


See User information
@Deniil
It's the interpreter.

This is just like television, only you can see much further.
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@kas1e
From what was said on that Morph Zone thread, to me it sounded that if endian issues with JIT JavaScript were solved, there would be "no need" to solve the endian issues with the Interpreted JavaScript? Any idea if that is right? (If it is, then bigfoot's JIT JS sounds like a potential solution to our problem updating Odyssey to recent WebKit...)

Author of the PortablE programming language.
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@ChrisH
Dunno, but as i understand it is 2 separate issues and separate code, which may interference with each other a very little. From another side if bigfoot working on JIT working on big endian, then probably to test it all properly he will in needs to fix and plain interpritator as well (if only there is no 2 totally separate code bases , one for JIT JS, and another one for plain JS, and they builds in depends on what is choiced in config).

Problem that JIT JS from bigfoot are in progress for too long as well, and possible will be never done because of time/busy/etc issues. So we need to just deal with plain JS issues.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: We so need an updated browser!
Just can't stay away
Just can't stay away


See User information
Sometimes you have to push other people a little bit to get some answers. kas1e summed it all up for everybody to see. afxgroup gave the answer I bet Hans was looking for.

@kas1e
So you, Fab and Deadwood have been working on Odyssey before and I remember you said there was 2 other guys helping to port it to AmigaOS. So if you say it's easy like just typing CMake into a Shell. So 5 guys, who have done it before, can't type 5 letters into a Shell window for several years. Don't come to tell it's slam dunk to a person who haven't used all the necessary tools possibly ever before. Also I'm not interested in PPC Mac's personally but your MorphOS friends have nothing but PPC Mac's so why don't they do anything ? Oh, ChrisH already commented a post from another forum where Bigfoot tried already but found out it was a very big job.

If the community is too outnumbered to keep web browsers up to date to the level of the rest of the world. Maybe it's time to give up !?

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: We so need an updated browser!
Quite a regular
Quite a regular


See User information
@TSK
You seem to be mixing up the JIT bigfoot was working on with the interpreter in JavaScriptCore.

This is just like television, only you can see much further.
Go to top
Re: We so need an updated browser!
Just can't stay away
Just can't stay away


See User information
@BSzili

Quote:
You seem to be mixing up the JIT bigfoot was working on with the interpreter in JavaScriptCore.

Maybe. So there's even more involved. Loads of work, it seems. And good knowledge of multiple computing platforms. And a load of developers.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@TSK
Quote:

If the community is too outnumbered to keep web browsers up to date to the level of the rest of the world. Maybe it's time to give up !?


Overpriced hardware, dead CPU => no new blood => less of all us => of course need to give up :)

I mean, that everything expected. Its big big surprise that we all still here, and have even what we have :) Our hope in terms of webbrowsers, is that someone still will support big-endian machines, and we can reuse that code. Because making browser by 1-2-3 ppls today are unreal.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: We so need an updated browser!
Quite a regular
Quite a regular


See User information
@TSK
Actually nobody is involved in fixing the interpreter, that's the problem.

This is just like television, only you can see much further.
Go to top
Re: We so need an updated browser!
Just can't stay away
Just can't stay away


See User information
Is it possible to build/test JavaScriptCore only or are bugs exposed only in the actual use?

Go to top
Re: We so need an updated browser!
Just can't stay away
Just can't stay away


See User information
@kas1e

I've been surprised how many people have promised to buy X5000 or A1222, many people popped up on forums recently planning to make come back to Amiga and even many new comers who doesn't know Amiga from the past. X5000 is making good spin and momentum.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@Capehill
Quote:

Is it possible to build/test JavaScriptCore only or are bugs exposed only in the actual use?


To be honest i for myself even didn't tried to dig in in all that, as i know that i can't deal with, and was hope for Fab, so i do not know how best to do and test it all.

But, i can say that whole build of odyssey designed that way: it builds logicaly different parts of webkit as static libraries, which is linked at end in whole binary:

1. libwtf.a - take about firt 3% of whole compilation.
Little one, about 0.5mb for me, and contain some basic stuff

2. libjsc.a - take another 10% of whole compilation. ~6.2mb of size. That one are java-script-core. And on the wiki of webkit writen that it can be used independently (so probably can be also tested and co that way). But what, how, where - i didn't dig in.

3. libwebcore.a - that mostly platform independed webkit core code. There is almost no platform specific changes, but whole core. Taked till 92% of whole compilation. Size about 80mb. There is DOM, CSS, SVG, loaders, webinstepctor, and all that heavy crap.

4. libwebkit-owb.a - that mostly platform depended code, almost 90% of all mos/aros/os4 changes mostly there (whole GUI, etc). Size about 3mb.

In end of all there is main.cpp , which i link together with those libs, and binary ready.

So, probably libjsc.a could be used and tested somehow without building whole odyssey.

Probably i need firstly build "broken js" version of 1.25 from github (1.5 years old webkit core). And then to see how it will be going, where and how bugs will arise and co.

But i just still in hope that Fab will made new version which i can just port as usual :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: We so need an updated browser!
Just popping in
Just popping in


See User information
I looked at this many moons ago, and now took some time with it again. What I did then was to apply the PPC-Mac patch for WebKit onto the Odyssey code. It was relatively straight forward, but since our WebKit is newer than the PPC-Mac patch, there's quite a lot missing pieces in the PPC-code. It's mostly what seems to be new calling conventions of already existing methods, f.i. low level stuff like or32() that takes its destination as registers or some sort of pointer structure, where there seems to be a new pointer structure. There's also some ABI stuff that might differ in MacOS vs AmigaOS.
I'm now basically cmaking it, finding missing methods as I go, and implement them with dummy code when I can't figure it out immediately. This way I'm hoping to get a full compile through, which of course won't work, but it'll be some sort of "proof of build". And then perhaps someone with some more PPC-knowledge could fill in the blanks, or at least give some pointers.

I have it in my GitHub: https://github.com/jaokim/odyssey, and the interesting parts reside in JavaScriptCore/assembler, f.i. MacroAssemblerPPC.h or PPCAssembler.h. Look for "#warning AmigaOS" where I've added missing stuff.

However, I don't have super high hopes on this materialising into something runnable very soon. My time is limited, and its kind of boring. But I do still feel some sense of progress... but it might also prove to be way to many changes for me to handle... Time will tell.

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
kas1e wrote:

Quote:
Overpriced hardware, dead CPU => no new blood => less of all us => of course need to give up :) I mean, that everything expected. Its big big surprise that we all still here, and have even what we have :) Our hope in terms of webbrowsers, is that someone still will support big-endian machines, and we can reuse that code. Because making browser by 1-2-3 ppls today are unreal.


that's why we love ya Roman

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@jaokim
Did you use patches from https://sourceforge.net/projects/leopard-webkit/files/602/Sources/ ?

I see that Tobias still works on it, and there is different revissions of webkit (old ones, new ones). Probably there should be something he can apply straigh forward.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: We so need an updated browser!
Just popping in
Just popping in


See User information
Why our community can't talk/support with Tobias? I think it could make life easier for all us. He can have a help, we can update Odyssey?

https://sourceforge.net/projects/leopard-webkit/files/602/Sources/


Edited by radzik on 2017/4/12 19:26:23
Amiga 2000 2 MB Chip ECS, Blizzard 2060/60 MHz 128 MB Fast, Picasso II+, Deneb USB, 160 GB & DVD-RW / OS 3.9
Amiga 1200, Blizzard PPC 233/040 256 MB Fast, BVision / OS4.0, OS3.9
Pegasos II 1 GB Radeon 9250 / OS4.1
---
http://radzikowski.ovh.org
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@jaokim

Did you manage to compile a working binary?


@kas1e

Any idea how hard adding WebGL support would be? I assume that the Webkit code already has it; just the AmigaOS-specific parts would have to be done.

Also, is the plugin API working in the AmigaOS version?

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work
Go to top
Re: We so need an updated browser!
Home away from home
Home away from home


See User information
@Hans
Quote:

Any idea how hard adding WebGL support would be? I assume that the Webkit code already has it; just the AmigaOS-specific parts would have to be done.


Technically and theoretically (and if i remember right as Fab says), it's all matter of just enabling on configuring time necessary flag for. It is should be -DENABLE_WEBGL:BOOL=ON probably. Whole build process done like this, for example if one want WEBSOCKETS, then just -DENABLE_WEB_SOCKETS:BOOL=ON, if WEBINSPECTOR, then -DENABLE_INSPECTOR:BOOL=ON.

So, i tried few days ago to rebuild it all with -DENABLE_WEBGL:BOOL=ON and nothing changes at all. Odyssey didn't search for any new headers, and nothing changes, it happy builds as before, like nothing changes. It even didn't try to find out new files to compile.

I also ask Deadwood about, if he doing it before, and he say that together with that turning ON on configuration time, it also needed to have special OpenGL headers called "Angle".
He also say that for version which is placed on github (that 1.25 one, where endian problems present), he remove those Angle files, as for AROS it was a bit buggy (software ones works, hardware not and he just skip it). But our port is based on 1.23 sources where those files may be keept.

So, long story short : or that sources which Fab upload of 1.23 version (on which my port based) didn't contain those special Angle files and was deleted as mos port didn't use it. Or, it have (i didn't find at moment), and need not only WEBGL=ON, but something else.

That where i stop, and probably i just need to ask WebKit developers to how enable it all properly. If anyone have time to check this out that will be good :)

Quote:

Also, is the plugin API working in the AmigaOS version?


Our version have DENABLE_NPAPI:BOOL=ON (as morphos one), and if i remember right we rewrite some part related to plugins, but only one plugin was exits : flash one, which sources we don't have and can't test if all works in terms of plugins or not.



Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 2 3 (4) 5 6 7 8 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project