MorphZone

Future-proof addresses

Samurai_Crow

# 1
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

Cross-post from the AmigaOS 3 forum:

Greetings! It just occurred to me that message port handles being addresses are always on even numbers due to alignment constraints. After looking at Gunnar von Boehn's additions to the 68080 and SAGA softcores, it occurred to me that using bit zero as a flag could be used to switch to a different message port encoding such as an enumeration. Once that is no longer address constrained, it could allow 64-bit addressing both on AmigaOS 3+ and ApolloOS. If MorphOS follows suit, great!
»19.07.25 - 11:37

Piru

# 2
MorphOS Developer

Posts: 598 from 2003/2/24

From: finland, the l...

What was the problem you try to solve with 64-bit messageports? This sounds like a solution looking for a problem.

Using some bits of addresses for "magic" information is asking for trouble. Just ask how easy it's to run AmigaBASIC on Amigas with 32-bit memory. Or how convenient it is that AllocEntry() uses bit 31 to indicate error condition.

Also, this isn't a generic solution to encode 64-bit addresses as many addresses can be odd.

If you go 64-bit do it properly with real 64-bit addressing everywhere. 32-bit legacy stuff can be run in a runtime environment.

No, MorphOS will not adopt stupid concepts.
»19.07.25 - 13:15

Georg

# 3
Acolyte of the Butterfly

Posts: 124 from 2004/4/7

Quote:

can be run in a runtime environment.

So the "boxes = evil" era is over?
»19.07.25 - 15:17

Samurai_Crow

# 4
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

The problems associated with having addresses used for handles of message ports also include lack of memory protection. Being able to map 32 bit functions into a 64 bit address space for backward compatibility is mainly for legacy code. A new message port structure for 64-bit addressing would be preferred but the old ones would still need to be kept around as long as Trance or any other 32-bit architecture stuff needs kept around. Alignment from the AllocMem() allocator has always been guaranteed to be aligned to 4-byte increments (sizeof APTR). Unless message ports don't need that alignment, bit 0 and 1 should always be 0 but we don't need to get too crazy.

As for bit 31 being an error code in one function, remapping that to be the sign bit of whatever word-size is in use would at least have an equivalence, if it is needed at all.
»21.07.25 - 11:15

Samurai_Crow

# 5
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

Quote:

No, MorphOS will not adopt stupid concepts.

Would a transition to a "message.device" be preferred? Send message and reply message existing code would become legacy in such an instance.
»21.07.25 - 11:53

Kronos

# 6
Moderator

Posts: 2456 from 2003/2/24

@Georg

A box? What a weird idea...

@Ninja-Pigeon

Sounds like a half measure that doesn't really fix anything.
»21.07.25 - 13:06

Piru

# 7
MorphOS Developer

Posts: 598 from 2003/2/24

From: finland, the l...

Quote:

Samurai_Crow wrote:
Would a transition to a "message.device" be preferred? Send message and reply message existing code would become legacy in such an instance.

I still don't understand the problem you're trying to solve here.
»21.07.25 - 16:17

Samurai_Crow

# 8
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

Every time I've tried to figure out ways to implement solutions for SMP and memory protection, I've been told that the way that handles using addresses, that enforced flat memory models, were non-conducive to solutions in those cases and unless that was changed in some way, they would continue to be unsolvable. This would be a light at the end of the tunnel for those previously "unsolvable" problems.
»21.07.25 - 18:04

Piru

# 9
MorphOS Developer

Posts: 598 from 2003/2/24

From: finland, the l...

Quote:

Samurai_Crow wrote:
Every time I've tried to figure out ways to implement solutions for SMP and memory protection, I've been told that the way that handles using addresses, that enforced flat memory models, were non-conducive to solutions in those cases and unless that was changed in some way, they would continue to be unsolvable. This would be a light at the end of the tunnel for those previously
"unsolvable" problems.

No, it would not.

I think you've misunderstood something, or someone has been explaining things badly. Being restricted to 4GB address space doesn't exclude SMP or memory protection. There are far bigger issues at the API/ABI level that block those, and there is no way around them (this is why there is no working SMP or memory protection). Use of bit 0 to have "64-bit messages ports" (whatever that means in practice) or introducing some exec message.device is not going to fix any of those issues.

Either way, if you introduce a new messaging system, you will be breaking the existing ABI. At that point, it doesn't really make sense to drag along the current concepts. A clean break would make much more sense, and then you could bake in SMP and memory protection from the start.

Note that this is not any kind of statement about MorphOS in specific nor does it specify any paths MorphOS might or might not take.
»21.07.25 - 21:34

jacadcaps

# 10
MorphOS Developer

Posts: 3220 from 2003/3/5

From: Canada

Quote:

Samurai_Crow wrote:
Every time I've tried to figure out ways to implement solutions for SMP and memory protection...

I think the only way you can convince us is by showing a working demo. Take AROS' source code and try to make it all work. Good luck.
»22.07.25 - 10:11

Samurai_Crow

# 11
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

Quote:

jacadcaps wrote:
Take AROS' source code and try to make it all work. Good luck.

Nobody tests AROS ABI v1 any more. They're so hung up on ABI v0 they don't care about 64-bits and AROS SMP.

Anyway, I'll go back to minding my own business with EEC (my fork of ECX) and seeing if I can get the bugs worked out of that first. If I can implement QBE as backend.library, AmigaE may get a new lease on life.

Ciao!
»22.07.25 - 17:04

Kronos

# 12
Moderator

Posts: 2456 from 2003/2/24

Quote:

Samurai_Crow wrote:

Nobody tests AROS ABI v1 any more. They're so hung up on ABI v0 they don't care about 64-bits and AROS SMP.

Maybe because pretty much everybody came to the conclusion that it would lead nowhere.

For systems that need binary compatibility (read MorphOS, OS4 AROS_68k) it was never an option.
Even going just for source code compatibility would be an issue as so much old stuff uses datatypes that won't just automatically adapt and expand to 64bits addressing.
And you still wouldn't have tackled anything beyond increasing the amount of useable RAM.

So yes to fix all that you would need completely new APIs.
This could be done by running the "classic" portion of the OS boxed in with a modern OS calling the shoots, or you could have a minimal modern OS running on extra cores/RAM that can be accessed with a limited API (think PowerUP, the OG x86 modules in Amitlhon or even Janus.library for those old bridgeboard).
»22.07.25 - 17:40

Samurai_Crow

# 13
Order of the Butterfly

Posts: 182 from 2009/12/10

From: Minnesota, USA

Quote:

Kronos wrote:
For systems that need binary compatibility (read MorphOS, OS4 AROS_68k) it was never an option.
Even going just for source code compatibility would be an issue as so much old stuff uses datatypes that won't just automatically adapt and expand to 64bits addressing.
And you still wouldn't have tackled anything beyond increasing the amount of useable RAM.

So yes to fix all that you would need completely new APIs.
This could be done by running the "classic" portion of the OS boxed in with a modern OS calling the shoots, or you could have a minimal modern OS running on extra cores/RAM that can be accessed with a limited API (think PowerUP, the OG x86 modules in Amitlhon or even Janus.library for those old bridgeboard).

Haiku with hosted AROS would be interesting but only if it supports pure, resident, reentrant code. Otherwise, just ditch AROS. At least Haiku is POSIX compliant enough to port Linux code more easily. I just wish that the Haiku users would get over their partiality of "native code" even though old BeOS source code is nearly unobtainable and suffers the same ills as AROS ABI v0 when running on 32-bit systems.
»23.07.25 - 01:34

jPV

# 14
Yokemate of Keyboards

Posts: 2171 from 2003/2/24

From: po-RNO

Quote:

Samurai_Crow wrote:
Haiku with hosted AROS would be interesting

Although a hosted AROS was just plain horrible on Linux, at least couple of years ago. Half of the things crashed or did work in an unexpected way. It was just impossible to do even minimal testing on it and I had to move to a full emulator to get a working AROS test environment.
The wiki based MorphOS Library - Your starting point for MorphOS
Software and other things made by me
»23.07.25 - 03:48

Georg

# 15

Acolyte of the Butterfly

Posts: 124 from 2004/4/7

Quote:

jPV wrote:
Although a hosted AROS was just plain horrible on Linux, at least couple of years ago. Half of the things crashed or did work in an unexpected way.

Hosted AROS is a normal Linux program so if AROS components themselves or a program run under it does something bad (like access bad address) it will much more easily show up as crash because of Linux mem protection. Whereas in native AROS (like in AOS68k or MOS?) because of none at all or less mem protection such bugs more easily go undetected and the OS and programs often keep on running as if nothing happened.

But debugging with AROS hosted is very easy and fast because you can run it as a whole in "gdb" and the whole OS with all tasks/libs system/user/whatever can be debugged symbolically.

Code:


(gdb) bt
#0  Graphics_51_RectFill (rp=0xe8d634d4, xMin=0, yMin=0, xMax=2559, yMax=18, GfxBase=0xe8854980) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/graphics/./rectfill.c:63
#1  0xe77b7c77 in __inline_Graphics_RectFill (__arg1=0xe8d634d4, __arg2=0, __arg3=0, __arg4=2559, __arg5=18, __GfxBase=0xe8854980)
    at /home/georg/aros/arosdeadwoodaltabiv0/alt-abiv0-linux-i386-d/bin/linux-i386/AROS/Development/include/inline/graphics.h:778
#2  0xe77b9eec in RenderMenuBar (mhd=0xe88a87a0, IntuitionBase=0xe8869ee0) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./menutask.c:984
#3  0xe77b9c52 in MakeMenuBarWin (mhd=0xe88a87a0, IntuitionBase=0xe8869ee0) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./menutask.c:925
#4  0xe77b7fad in DefaultMenuHandler (taskparams=0xffffc8d8) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./menutask.c:167
#5  0xe7680270 in __inline_Exec_InitSemaphore (__arg1=0x0, __SysBase=0x0)
    at /home/georg/aros/arosdeadwoodaltabiv0/alt-abiv0-linux-i386-d/bin/linux-i386/gen/rom/exec/exec/include/inline/exec.h:1321
#6  0xffffc8d8 in ?? ()
(gdb) print rp
$13 = (struct RastPort *) 0xe8d634d4
(gdb) print *rp
$14 = {Layer = 0xe8d63420, BitMap = 0xe90189d0, AreaPtrn = 0x0, TmpRas = 0x0, AreaInfo = 0x0, GelsInfo = 0x0, Mask = 255 '377', FgPen = 0 '00', BgPen = 0 '00', 
  AOlPen = -1 '377', DrawMode = 0 '00', AreaPtSz = 0 '00', linpatcnt = 15 '17', dummy = 0 '00', Flags = 0, LinePtrn = 65535, cp_x = 0, cp_y = 0, 
  minterms = "00000000000000", PenWidth = 0, PenHeight = 0, Font = 0xe8a31b10, AlgoStyle = 0 '00', TxFlags = 0 '00', TxHeight = 13, TxWidth = 7, TxBaseline = 9, 
  TxSpacing = 0, RP_User = 0x0, RP_Extra = 0x0, longreserved = {0, 0, 0, 0, 0, 0}, reserved = "00"}
(gdb)

It does not matter if something is in Forbid state, or deadlock, or whatever. CTRL-Z gets you in the debugger. You can show backtrace of running Exec tasks or any other task. You can reboot in fraction of a second. Even simple method like having tons of debug output with kprintf is extremely fast and most of the time will not slow things much at all. You can filter away some output with "grep" if not. You can use hardware watchpoints (tell gdb to interrupt when a certain mem address was written/read without slowdown).

»23.07.25 - 05:02