Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
|
Poster | Thread | wawa
| |
Re: ARPi - AROS on Raspberry Pi Posted on 28-Aug-2018 14:01:26
| | [ #1 ] |
| |
|
Elite Member |
Joined: 21-Jan-2008 Posts: 6259
From: Unknown | | |
|
| @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. |
| Status: Offline |
| |
|
|
Poster | Thread | matthey
| |
Re: ARPi - AROS on Raspberry Pi Posted on 29-Aug-2018 17:46:01
| | [ #1 ] |
| |
|
Elite Member |
Joined: 14-Mar-2007 Posts: 2019
From: Kansas | | |
|
| 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).
|
| Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|