AxRuntime

[deadwood]

I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.

[OlafS3]

when you have done the foundations I would be really interested in it. It is a little like Aros 68k was, with it you could mix Aros and Amiga components and create something new. AxRuntime offers the chance to do the same with Linux. Great project 

[cdimauro]

I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.

Not only that: if the message is a complex structure containing pointers... then passing it to another process doesn't work either.

[deadwood]

@cdimauro

True, that's the case of "randezvou" address in memory. Programs using this will be problematic at least.

[deadwood]

when you have done the foundations I would be really interested in it. It is a little like Aros 68k was, with it you could mix Aros and Amiga components and create something new. AxRuntime offers the chance to do the same with Linux. Great project 

The question is what would be the "next step" from user perspective. You described Wanderer as Linux desktop replacement. That's sizable amount of work and Wanderer will still be subpar to any "Linux" desktop. It would be good to figure out what are smaller steps that are useful to people. Another thing to think through is whether we can engage not only current Amiga community, but also people who used Amiga back in a day and today use Linux. Give them a way to reminiscence past without sacrificing what they are used to.

[OlafS3]

I am not sure if both groups are not different. You have current community and you have people outside, in best case with amiga memories. I think to make users of current community happy a amiga desktop is best even if it is not on same level as current linux desktops. To attract users from outside with some amiga background perhaps using a normal desktop with lots of configuration is best and adding amiga software or to be precise amiga-like linux software.

[cdimauro]

Well, here we're talking of having Amiga applications ported to Linux. So, not Amiga-like: they ARE Amiga applications. 


The point is how much important is trying to port Wanderer to Linux. Wanderer mimics our beloved Workbench, but both were/are quite limited, and is the reason why alternatives (DOpus is the best example) were born. IMO it's better to port the alternatives, at this point in time.


A future thing which might be implemented is porting 68K applications as well. I mean: applications that use 68K assembly in their source codes. So, you have the possibility to compile them, getting native binaries (and much better performances, since you can optimize the generated native codice way better).
The 68K emulator/JITer could stay on a shared library, to reduce the footprint AND making its core easy to update (while not requiring a recompilation of all applications. Unless for big / major changes).


This is something which I think about since years (as well as the 68K "virtualizer". Which is similar to the work being done on Michal's Emu68), but it's a quite complex project.


With the same approach, many things from the original hardware could be ported to native applications. O.s.- friendly applications (e.g.: applications that relay on the Amiga hardware, but using the o.s. APIs for accessing it) should be easier to port (most of the code is already on AROS). But this is, again, a complex stuff to implement.

[magorium]

I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.

Pardon the intrusion but isn't that what IPC (on/via the host system) can be used for ?

You can then even share address space (virtual memory) between processes. Perhaps a bit more complicated than directly communicating between two applications but can be implemented in a way that is fairly easy to use. Free Pascal for instance has such a (3th party dynamic loadable) library (supporting several hosts such as Windows, Mac, Linux, etc.). That makes things (relatively) easy to use, so that for instance you can communicate amongst different programming/scripting languages, e.g. Free Pascal, Python, Go, C, etc.

Would love to test that with a proof of concept with Free Pascal but axrt looks to be so intertwined with gcc that it would require a lot of hoops (and loss of control) to get that working for FPC.

To to get back on point on the last messages of this thread on what axrt (imho) means is that such an implementation is an excellent example of what axrt could be used for: Test such a concept, then try to 'backport' that to pure Aros code so that Aros itself can be improved.

[deadwood]

@magorium

I haven't looked in IPC or other forms that can be used, so I won't comment on this part.

You mentioned you asses Ax is intertwined with GCC - what do you mean by this? Can you given an example?

[deadwood]

I am not sure if both groups are not different. You have current community and you have people outside, in best case with amiga memories. I think to make users of current community happy a amiga desktop is best even if it is not on same level as current linux desktops. To attract users from outside with some amiga background perhaps using a normal desktop with lots of configuration is best and adding amiga software or to be precise amiga-like linux software.

I think they are different and will require different approaches to attract. It's a complex problem where it is probably easier to attract people from current community, but the long term success will be measured by ability to attract people from outside.

[OlafS3]

yes indeed

I am (up to now) not a big linux user and only installed a free version now and then to look at but amiga has a number of nice advantages compared f.e. to windows. Simplicity is one and what I like are concepts like datatypes or xad and general installing drivers by copying in a directory. That should be transferred somehow to a new platform. And of course you need different approaches for current community and for potential users outside that never used amiga or only a long time ago. In that context wanderer is certainly potentially more interesting to current community. For the others using a "modern desktop" and configuring it is certainly the better approach. I personal would propose to concentrate first on the group that is easier to become interested, current community. To use another desktop later not sounds like that big problem to me. Also features like mounting adf or ISO are important for current community (diskimage device).

One thing I like about magellan (and miss at wanderer) are filetypes. You can define a filetype for any kind of file (I use ending for it like .png) and then attach icon, define context menu and define what happens if it is double clicked. Is that somehow possible?

[magorium]

@magorium

I haven't looked in IPC or other forms that can be used, so I won't comment on this part.

That is ok. Just saying that if someone out there would feel inclined to do so one could add a generic platform independent shared lib for IPC communication and add to axrt or simply use it from their individual AROS application(s).

You mentioned you asses Ax is intertwined with GCC - what do you mean by this? Can you given an example?

Sure thing :-)

Albeit that said, atm it is hypothetical based on what i've read in the readme/docs and source-code of axrt.

In case you are able to remember, it is similar to the situation you helped me with when linking against static aros libraries (in opposite to the normal way of doing things with FPC, namely opening/closing the shared libraries manually from disk and FPC assigning the library entry points in order to make API calls).

If i look at your distribution calculators example's makefile, i read:

# axrt.ld needs to be added to list of objects passed to linker for proper section ordering
# axrt.specs needs to be used for default libraries selection

That means i need to use a custom linker script. That should be doable for Free Pascal.
Then there is "the library selection", that links the libraries... ok, i have no idea right now but, let's assume i am able to do such a thing with FPC.

Then, i downloaded the deb file libaxrt-2.0-dev_40.2-1_amd64.deb and extracted the readme which reads, in chapter 4 (How do I build an application using runtime?):

4.3) Detailed - Linking

    i.) Add startup.o and axrt.ld to objects being linked, example:

    OBJ += /usr/lib/x86_64-linux-gnu/startup.o /usr/lib/x86_64-linux-gnu/axrt.ld

    ii.) Select axrt.specs linker specs file, example:

    LDFLAGS = -specs=/usr/lib/x86_64-linux-gnu/axrt.specs

    iii.) Add additional linker libraries to resolve symbols, example:

    -lmui -lamiga -lstdc.static -lstdc -lcodesets -lkeymap -lexpansion -lcommodities
    -ldiskfont -lasl -lmuimaster -ldatatypes -lcybergraphics -lworkbench -licon
    -lintuition -lgadtools -llayers -liffparse -lgraphics -llocale -ldos
    -lutility -lexec -lm

So, i need to add startup.o (same as the static linking solution back then as mentioned at the beginning of this part of my reply).

Let's take a look at the startup file in your tree (https://github.com/deadw00d/AROS/blob/5f70d1d7564124c0370855e921a256651a078e5f/arch/all-runtime/axrt/startup/startup.c)

In the first part afaik, i see there the same symbols that needs to be defined/exported in my Pascal source, according to my wishes. Note, that when i do so
i have already given control over from FPC startup code to AROS startup code, meaning that if anything goes wrong FPC is not able to catch it, c does but that does not help me in particular :-)

Then, i go further down and i see some other (for me) terrifying startup code, this time on/for the Linux side :shivers:

I have no idea what this line of code does:

const char dl_loader[] __attribute__((section(".interp"))) = "/lib64/ld-linux-x86-64.so.2"

But assuming that it defines a variable for the linker to pick up, and the fact that it points to ld (and even more because it seems a static location) sounds horrifying to me.

Assuming that my code is still alive, then we see a function named __runtimestartup, that sets and runtime environment and kickstarts and seems to be invoked from routine _axrt_start, that routine seems to be resolved by the linker and automagically invoked ?

.. and finally we arrive at open64, which also seems to be invoked due to some linker magic ?

Every time the linker matches the symbols that get called automagically, i literally have lost control over to the c runtime library (whatever runtime library
that is, be it AROS or linux-host. referred by me as "gcc intertwined"). And that is assuming that everything linked as intended. If not then it is for me a needle in the proverbial haystack to find out what went wrong where exactly (and why).

That is, if i all interpreted the documentation and source-code correctly.

And then there is the question of the axrt.so file. I can load and open it, but is there anything else that needs to be done from my side of things ? e.g. usually one opens a library and calls a (specific) function in order to initialize things properly.

Does that answer the question that you've asked ?

[deadwood]

@magorium

Thanks, that is enough explanation. I assume FPC can compile executables for Linux and can open ELF shared object (dlopen-like)? Is that they case?
If yes, would you be interested in working together to see if FPC can use AxRuntime under Linux? Many of the things that you mentioned are effect of dual-run nature (being started from Linux and from within AxRuntime). For first iteration for Pascal, things should be fairly easy IMHO and it would help me greatly to validate that AxRuntime can be used from another language.

[cdimauro]

I think message passing will be doable across separate address space processes. Message, unlike a memory location (a pointer passed around), is always "owned" by one of the processes, so you can think of copying the message back and forth between processes address spaces. Of course the sender could be modyfing a message after it was sent (and that's agaist the idea of messages) and this case won't work.

Pardon the intrusion but isn't that what IPC (on/via the host system) can be used for ?

You can then even share address space (virtual memory) between processes. Perhaps a bit more complicated than directly communicating between two applications but can be implemented in a way that is fairly easy to use. Free Pascal for instance has such a (3th party dynamic loadable) library (supporting several hosts such as Windows, Mac, Linux, etc.). That makes things (relatively) easy to use, so that for instance you can communicate amongst different programming/scripting languages, e.g. Free Pascal, Python, Go, C, etc.

IPC is a broad term: it's a general term to indicate that two or more processes can communicate.


How is it done is the tricky stuff, and strictly depends on how it's implemented.


Amiga o.s. uses message passing on a fully-shared address space, with all goods (superfast) and bad things (no security / no ownership / no solidity) that can happen.


I don't now the IPC implementation that you talked about, but I assume that it's a form of message passing, mapping those messages to the various processes' virtual memory spaces (not necessarily on the same virtual addresses), and probably some sort of marshalling (otherwise it's difficult to see how your mentioned languages can communicate, since they are very different).


However marshalling means also slow, especially if you want to pass complex structures. It also means that the existing Amiga applications require could requite notable changes to use this new mechanism.

[Amiwell]

It could remain a project for the developers