@bobson

perhaps at this point a reference link should be included in the initial post, not only for those who want to support the initiative, but especially for those who would like more in depth explanation without getting lost in side walk arguing:
https://www.patreon.com/michal_schulz

at least thats what i would do.

@michalsc

is there any more specific plan how to proceed, how this is gonna be organized in terms of development and how are you to be supported, except money?

since you bring up arix, which i support, even if it isnt of an essential interest for me as a m68k -amiga troll, the development, if open, will likely be taking place on your github account, since there is no agreement as of if merging arix back into aros trunk as a target is desired.

i understand that arm specific and arix agnostic code would be then remerged from there back into aros repo.

now , there was talk about some special new version of compiler that is required feature wise for your intentions to explicitely compile aros internal structs big endian.
what compiler is it? clang?

if we are to use something else than default gcc-4.6.4, optional gcc-6.3.0 or experimental gcc-8.1.0 the build system and the code pool will certainly need further adaptations.

i can at least test here changes, that may be necessary, with our still actively used legacy compilers before they get pushed to aros repo, to ensure that aros as such (nightlies) still builds and works.

@michalsc

Quote:

If you would have a look at AROS code, e.g. here, at kernel_ipi.h, you would notice we are already working on that.

Is https://github.com/michalsc/AROS a copy of the primary AROS development tree (the one used for nightly builds), or is it a fork of some sort?

_________________
"Unix is supposed to fix that." -- Jay Miner

Quote:

michalsc wrote: Yes, such Forbid()/Permit() could be done it it would be massive performance loss since you would replace one byte increment (TDNestCnt) by a byte increment followed by full stop on all cores (the Forbidding core sends IPI to all other CPUS, then each CPU has to confirm that it is entering Forbid/Stop state, the forbidding core has to make absolutely all other cores stopped, i.e. wait for all cores to send the IPI back, before it returns to the caller). Permit would be less restricted since there would be no need to wait/send confirmation IPIs. The problem is, even if you try to replace as much forbid/permit pairs with semaphores, there still will be a plenty of this nasty calls.

I wonder what the logic was behind the Forbid/Permit macros. I would have thought they would have used a function to increment the Execbase counters and, if 0 or becoming not 0, write an interrupt mask value to one of the Paula registers to actually turn off/on whatever interrupts were necessary to disable multitasking (or all interrupts). Maybe I'm wrong (I haven't found the code), but it looks like the interrupts still happen, the Execbase counters are checked, and if disabled, then just return without changing anything? I was thinking this system they had would save interrupts but maybe not. It would be possible for the custom chips to read the Execbase counters if in chip ram but I don't see anywhere where this is done (not part of the interrupt process anyway).