Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
109 user(s) are online (55 user(s) are browsing Forums)

Members: 0
Guests: 109

more...

Headlines

 
  Register To Post  

Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
I'm a bit giddy and happy! I have from time to the other been working on JAmiga. Today, I however lost encouragement. With JAmiga.

However, still determined to get Java to Amiga, I persuaded my previous JamVM path. And have made success!

Me and kas1e have previous discussed a strange relocation error which revolved around elf.library shouting out a requester about "Unsupported reloc". Kas1e found quite a lot of information, which I have tried with, to minor avail. Today, I however searched some more, and tried some other things.
The solution was easy: first, do everything kas1e suggest, i.e. remove any TLS stuff. And then, what I found out by chance, you need to remove all "__thread" definitions you might have left in your code. They hsould be within #ifdef HAVE_TLS, but I had one spare lying around. And with that removed, the relocation error disappeared. So, I now have a JamVM crashing! Which is great!

Some background info on the TLS stuff. TLS stands for Thread Local Storage, and is a way for multi threaded programs to store thread local data. Basically, if you want a global object available for your thread, you can't use a static variable, since that will be shared by all threads. Introducing TLS, which relocates the memory dynamically by adding some non-standard elf-stuff. And this is controlled by the __thread keyword. A declaration "int __thread myVar;" is then defined as a thread local storage, and gets some special attention in our elf binary. Apparently, which kas1e found out, GCC from the Amiga adtools is built with TLS support enabled by default, so by just having a __thread keyword will trigger the elf magic -- which elf.library doesn't support.

So, to conclude, keep looking at the JAmiga blog, where I will post a new entry soon of my new JamVM progress.

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: Reloc, JAmiga and JamVM
Just can't stay away
Just can't stay away


See User information
\o/

Go to top
Re: Reloc, JAmiga and JamVM
Home away from home
Home away from home


See User information
@joakim

Happy to see progress on this project

Go to top
Re: Reloc, JAmiga and JamVM
Not too shy to talk
Not too shy to talk


See User information
Keep up the good work man!

Go to top
Re: Reloc, JAmiga and JamVM
Quite a regular
Quite a regular


See User information
Go on! We need the java platform.


Retired
Go to top
Re: Reloc, JAmiga and JamVM
Just can't stay away
Just can't stay away


See User information
Quote:
So, I now have a JamVM crashing!

I'm happy you are happy

Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr
Go to top
Re: Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
For the ignorant like me, what is JamVM compared to Jamiga? Is it a library to be used together with Jamiga, or is it another VM engine implementation to replace Jamiga? I didn't find an answer to that in the 2012/2011 blog posts.

Go to top
Re: Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
@billt

Good question! JamVM is a virtual machine, just like JAmiga. So JamVM replaces JAmiga.

Then there is the class library which need to be adapted to Amiga stuff, such as using bsdsocket.library for network stuff (which I have started on for JAmiga and can re-use), file I/O, and GUI. Basically, with me moving to JamVM, I can focus on Amiga-specific stuff, and not re-implement what has already been done in JamVM.

Another possible way to think of: JamVM/JAmiga is the CPU, and the class library is the OS. Sort of.

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
Thank you for helping me to understand. I had an idea of what the class library was and what Jamiga itself was, but got confused about the new JamVM talk.

I'm very excited to see you talking Java8. Very nice to see that we're not all hoping for Java5 someday...

Go to top
Re: Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
Sounds great! Keep it up!

/Me, myself and A1G4!
Go to top
Re: Reloc, JAmiga and JamVM
Just can't stay away
Just can't stay away


See User information
@thread

I think nobody noticed this Jamiga update

Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr
Go to top
Re: Reloc, JAmiga and JamVM
Home away from home
Home away from home


See User information
@Elwood
Thanks for the heads-up. Seems good.

Although it sounds like limitations of our pthreads implementation need to be documented better (or at all?!?).

Author of the PortablE programming language.
Go to top
Re: Reloc, JAmiga and JamVM
Quite a regular
Quite a regular


See User information
\o/ \o/

AmigaOne X5000
Radeon HD 7700
Go to top
Anonymous
Re: Reloc, JAmiga and JamVM
Thanks, Java is really badly needed!

Go to top
Re: Reloc, JAmiga and JamVM
Just popping in
Just popping in


See User information
@ChrisH: Yes, more documentation on the inner details of the pthread implementation would be needed. More specifically how signals are used/handled.
[Pseudo-technical ramblings will follow]

The pthread library for instance lacks pthread_sigmask(). (pthread_sigmask() is supposed to tell us which signal the pthread responds to. The same thing that sigprocmask() does for an entire process). I assume this is due to the way Amiga processes work, compared to how pthreads work. As I understand it, each pthread is in the Amiga implementation mapped to an Amiga Process. Each Amiga Process can be signalled on its own, whereas in the "real" pthread world, i.e. Unix/Linux, a pthread is more a "side track of execution" within its starting process, and not a separate child process. In a pthreaded program, it isn't possible to signal one specific pthread from a user perspective, you rather send the signal to the entire process, which then, through pthread_sigmask, decides if a pthread should handle it.

The reason for not having a pthread_sigmask, might be that we don't have a sigprocmask() call either. Or, we have it in clib2, but not in newlib. Perhaps it just wasn't possible to implement pthread_sigmask(), without knowing exactly how sigprocmask() is implemented, and trying to mimic that behvaiour in newlib. But I'm just guessing.

Anyhow, in JamVM we have a Signal Handler pthread, which should take care of any signals sent to JamVM (i.e. Ctrl-C and such). But in the Amiga implementation, this Signal handler is really just a child process to the main JamVM process, and signals sent to the main process won't reach the Signal Handler -- at least not without some manual signal proxying "magic".

I might have been able to use the pthread implementation, and just made my own pthread_sigmask. But given I needed som signal proxying magic, I need to hook those bits in together with all the other pthread calls. And furthermore, I don't really know what kind of signals the pthread implementation uses, if any.

Blah blah blah blah.
[/Pseudo-technical ramblings end here]

I'm not really one hundred percent sure of all my claims above, but I can at least for certain tell you that I now finally managed to get a "Hello World" running using JamVM. There are a few more details in the JamVM engine to tend to, but I should be able to continue the real work on integrating the Amiga stuff, more specifically networking.

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top

  Register To Post

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project