@cdimauro

Quote:

cdimauro wrote: However, a 64 bit architecture still allows to do the same and gather some advantage (e.g.: using the >4GB space as RAM: or RAD:, or for caching filesystems' blocks in memory).

So, nothing useful at in the age of ever faster flash memory.

And changes nothing whether AROS runs 32bit ARM/x86 in some big-endian mode with a build in 68k-EMU or if runs on the EMU directly.

At the very least you would need some basic API to "call out", similar to what Amithlon did. Mind you x86 was still single core 32Bit at that time, but no reason why a similar method couldn't be used on 64Bit multicore HW.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: However, a 64 bit architecture still allows to do the same and gather some advantage (e.g.: using the >4GB space as RAM: or RAD:, or for caching filesystems' blocks in memory). So, nothing useful at in the age of ever faster flash memory.

IF you have that memory in the system, yes. Otherwise (underpowered/old 64-bit system), it IS useful.
Quote:

And changes nothing whether AROS runs 32bit ARM/x86 in some big-endian mode with a build in 68k-EMU or if runs on the EMU directly. At the very least you would need some basic API to "call out", similar to what Amithlon did. Mind you x86 was still single core 32Bit at that time, but no reason why a similar method couldn't be used on 64Bit multicore HW.

No, no API is required and nothing like Amithlon. As I've said before, it should be something like Emu68k. So, the system is purely big endian (from a data access perspective).

This way you can freely mix 68k applications with AROS x86/x64 applications, because the AROS system is substantially working like a big endian system. Which means: exactly the same integration that OS4 and MorphOS provide thanks to Petunia and TranceJIT, respectively.

@cdimauro
Currently on x86, deadwood is tying together all AROS brunches so that they all run transparently.
https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1114&rowstart=0

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: @cdimauro Currently on x86, deadwood is tying together all AROS brunches so that they all run transparently. https://www.arosworld.org/infusions/forum/viewthread.php?thread_id=1114&rowstart=0

I know it very well, but that's something different from the current topic (which is: first class 68k apps running on AROS).

@cdimauro

Quote:

cdimauro wrote: This way you can freely mix 68k applications with AROS x86/x64 applications, because the AROS system is substantially working like a big endian system. Which means: exactly the same integration that OS4 and MorphOS provide thanks to Petunia and TranceJIT, respectively.

Don't know why it is so hard to understand, mixing 32 and 64Bit is just as much a nogo as mixing little and big endian.

If you want both side accessing the same Amiga API that is.
So many pointers in open system structures that the 64Bit side could do nothing beyond 4GB (and very little beyond 2GB due to "signed" pointers) without relying on some special API.

Even if this API is just AllocMem(1000000000,MEMF_THIS_REALLY_CANT_BE_SHARED_64).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

64 bit etc is going to far
32 bit and integration as on mos/aos4 is enough
do it and we may drop mos/aos4

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: This way you can freely mix 68k applications with AROS x86/x64 applications, because the AROS system is substantially working like a big endian system. Which means: exactly the same integration that OS4 and MorphOS provide thanks to Petunia and TranceJIT, respectively. Don't know why it is so hard to understand, mixing 32 and 64Bit is just as much a nogo as mixing little and big endian. If you want both side accessing the same Amiga API that is. So many pointers in open system structures that the 64Bit side could do nothing beyond 4GB (and very little beyond 2GB due to "signed" pointers) without relying on some special API. Even if this API is just AllocMem(1000000000,MEMF_THIS_REALLY_CANT_BE_SHARED_64).

Don't know why it is so hard to understand, this is NOT about mixing 32 and 64Bit, rather to have a 32 bit system (fully 32-bit and nothing else!) which could take advantage of 64-bit memory in SOME cases.

Anyone recalling MacOS X Tiger? Something similar (but NOT the same).

@cdimauro

Quote:

cdimauro wrote: @Kronos Don't know why it is so hard to understand, this is NOT about mixing 32 and 64Bit, rather to have a 32 bit system (fully 32-bit and nothing else!) which could take advantage of 64-bit memory in SOME cases. .

So you do want the AllocMem(1000000000,MEMF_THIS_REALLY_CANT_BE_SHARED_64) API

Which is kinda the opposite of

>In fact, it works only on 32 bit architectures (even using 64 bit architectures
>like ARM64 or the latest PowerPCs, your have to cripple the applications
>address space to 32/31 bits).

However you want to slice that cherry, it will always be a half measure not fixing any real issues doomed to be a dead end.

Once you implemented that AllocMem flag you would need to adapt and recompile any app that should take advantage of it, at which point you may just as well offer more and better APIs to let these apps use the full potential of the HW (or at least be a bit less constraint).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: @Kronos Don't know why it is so hard to understand, this is NOT about mixing 32 and 64Bit, rather to have a 32 bit system (fully 32-bit and nothing else!) which could take advantage of 64-bit memory in SOME cases. . So you do want the AllocMem(1000000000,MEMF_THIS_REALLY_CANT_BE_SHARED_64) API Which is kinda the opposite of >In fact, it works only on 32 bit architectures (even using 64 bit architectures >like ARM64 or the latest PowerPCs, your have to cripple the applications >address space to 32/31 bits). However you want to slice that cherry, it will always be a half measure not fixing any real issues doomed to be a dead end. Once you implemented that AllocMem flag you would need to adapt and recompile any app that should take advantage of it, at which point you may just as well offer more and better APIs to let these apps use the full potential of the HW (or at least be a bit less constraint).

Again, no: that's not what I want -> No API needed. Let's me clarify, because the discussion talked about similar, but not the same topics.

1) The request / idea was to have 68k applications running as first class software on AROS on x86/x64 systems, ARM, etc.. This is possible only by compiling AROS in big endian. So, native for ARM and Power PC, or by a proper compiler for x86/x64. That's the most important thing, because this is the topic of the thread.

2) I've said that this doesn't work on 64 bit systems, unless you cripple them and let them work with 32/31 addresses.

3) I've added the point 1) could still take some benefit from a 64 bit system by using (INTERNALLY) the additional memory for implementing RAM:, RAD:, caching of the filesystem.

All of that does NOT require any new API: just the existing ones. Point 3) can be implemented without APIs, because it's an INTERNAL thing.

I hope that it's clear now.

@cdimauro

Quote:

cdimauro wrote: . Point 3) can be implemented without APIs, because it's an INTERNAL thing. I hope that it's clear now.

Sure you want to create the API, hide it away and only make it useable in the form of a pointless non-feature

Stupid idea stays stupid idea.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: . Point 3) can be implemented without APIs, because it's an INTERNAL thing. I hope that it's clear now. Sure you want to create the API, hide it away and only make it useable in the form of a pointless non-feature Stupid idea stays stupid idea.

Well, told by one which is not able to understand that NO API is needed after several times that I've stated it, then it's a compliment.

@cdimauro

So what are gonna do without an internal API for that stuff?

Hardcode it into the RAD:-driver hoping that things never change?

No matter how you do it, RAM-disks are pointless for anything but a scratch drive for which the 1-2GB it can handle in current NG systems is more than enough.

-> half measure solving a non problem

-> -> far worse than doing nothing at all

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro So what are gonna do without an internal API for that stuff?

I know how to implement it, but it's YOU that raised the need for an API in those case, so it's up to you to PROVE it!


Quote:

Hardcode it into the RAD:-driver hoping that things never change?

No hardcoding is needed. The RAD driver is... a software. And software can be written to take into account the normal scenario or the new one.
Quote:

No matter how you do it, RAM-disks are pointless for anything but a scratch drive for which the 1-2GB it can handle in current NG systems is more than enough.

That's YOUR opinion.

But if it's pointless for you then you can complete remove it: then let me know how your post-Amiga OS works without a RAM device...
Quote:

-> half measure solving a non problem

Again, YOUR opinion.
Quote:

-> -> far worse than doing nothing at all

LOL: and here elementary logic died. : : :

@cdimauro

Quote:

cdimauro wrote: The RAD driver is... a software. And software can be written to take into account the normal scenario or the new one.

Yep a SW that either "asks" the kernel if and how much extended RAM there is (an API) or does things itself that should be done in the kernel (hardcoded).


As for it being pointless, have been running NG systems for 22 years, starting with 128MB on the Peg1, 1GB on Peg2 and MacMini and now 1.4-1.7GB on PowerMacs and PowerBook.

Plenty of time where I wished for more system RAM for applications, can't remember ever needing/wanting a bigger RAM disk.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: The RAD driver is... a software. And software can be written to take into account the normal scenario or the new one. Yep a SW that either "asks" the kernel if and how much extended RAM there is (an API) or does things itself that should be done in the kernel (hardcoded).

Hint: RAM, RAD and filesystem caching is SYSTEM software. They don't need to ask -> no API needed.
Quote:

As for it being pointless, have been running NG systems for 22 years, starting with 128MB on the Peg1, 1GB on Peg2 and MacMini and now 1.4-1.7GB on PowerMacs and PowerBook. Plenty of time where I wished for more system RAM for applications, can't remember ever needing/wanting a bigger RAM disk.

Np, but it's, again, YOUR experience.

@cdimauro

Quote:

cdimauro wrote: @Kronos Hint: RAM, RAD and filesystem caching is SYSTEM software. They don't need to ask -> no API needed..

Which in the 21st century go thought interfaces provided by the kernel.

That driver needs to access HW registers or the BIOS to determine how much RAM there is and where it is located during setup.

Everytime it wants to access that memory it has to switch the CPU to 64bit mode and back.

May all be trivial, but a driver is not the place to do such stuff.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: @Kronos Hint: RAM, RAD and filesystem caching is SYSTEM software. They don't need to ask -> no API needed.. Which in the 21st century go thought interfaces provided by the kernel. That driver needs to access HW registers or the BIOS to determine how much RAM there is and where it is located during setup. Everytime it wants to access that memory it has to switch the CPU to 64bit mode and back. May all be trivial, but a driver is not the place to do such stuff.

It depends on the specific processor.

Both x86 and PowerPC support PAE extension in 32-bit mode, which allows to use the memory after the 4GB. So, no 64-bit execution mode is needed.

Yes, you've to query the system to check how much memory you've but this is already part of the regular startup/init code.

Here you just need to keep track of how much memory is beyond the normally usable memory and that's it: just use it (using the MMU to map it somethere in the system memory, when it's needed).

Going back to the architectures, I don't know if ARM has something like PAE. Using PowerPCs in 64-bit mode only for this is a complete non-sense, since you can use the above PAE.

x64 is a different story. Here you can compile a platform forcing to use 32-bits for pointers. This was the so called x32 ABI which was proposed by Intel years ago, but it never gained consensus.
However, this is very interesting in this context, because you're anyway forced to have a 32-bit system. But in this case you can take advantage of doubled register file (16 instead of the 8 available with x86) AND you (kernel) can still directly access memory beyond 4GB (no MMU mapping is required).
For this reason, an AROS port for x32 AND using big endian will be the preferred platform for this idea instead of x86.

@fishy_fis

Quote:

... Intergrated Petunia/Trance Style 68k CPU Emu In AROS ...

Michal Schulz started to develop AROS on ARM BE (big endian) and then he was carried away developing a transparent 68k emulator for this system, it should have worked like the 68k emulation in AOS4 or MOS, but ended as 68k emulator in PiStorm. I don't know if it's still big endian.

@OneTimer1

As we say in português, he felt victim to one's own success xD

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@OneTimer1

so szulc started with aros be on arm with integration
but failed and made emu68?
nobody need this shit pistorm
its time to revert to original plan