I'm curious about a few things listed in the update: - A new semaphore-type called Mutex that is Forbid-Free. What were the forbid() issues with the old semaphores? I'm not sure how this new Mutex differs in functionality from the old one. - A new library that supports most of the POSIX thread (pthreads) API. Is this a pthreads.library, or something else? - Apart from the thigs listed (such as shared-object support), are there any other new things developers should know about? - When can we expect an updated SDK, allowing us to use these new features?
- A new semaphore-type called Mutex that is Forbid-Free. What were the forbid() issues with the old semaphores? I'm not sure how this new Mutex differs in functionality from the old one.
They mostly likely replaced the forbid() whit some kind of spinlock fix, the question is when will se replacement for forbid() in general, we need some kind of way to ask other programs / OS / drivers to stay hell out owner business, when changing or updating list structures in reaction, or some other place in the OS.
It?s a step in the direction of SMP support.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
- A new semaphore-type called Mutex that is Forbid-Free. What were the forbid() issues with the old semaphores? I'm not sure how this new Mutex differs in functionality from the old one.
The functionality is the same. However, there has been an unfortunate tradition on AmigaOS to make all structures public, so there is little we can do to change existing structures. The SignalSemaphore is one of those cases. It's counter is an int16. That means for checking whether it is free or not you must call Forbid(), examine the fields and possibly modify it, and then call Permit() again. The PowerPC's address reservation feature does not work on 16 bit integers.
The Mutex works like a semaphore, but instead uses an internal int32 for the counter. That means that if the mutex is free, no forbid is needed to obtain it. If it is occupied, the task will be put to sleep anyway, so it's not the big issue, but the general case is that the mutex is free, so having a forbid-free mutex improves performance as well as (as LiveForIt already pointed out) being more SMP-friendly.
Quote:
- A new library that supports most of the POSIX thread (pthreads) API. Is this a pthreads.library, or something else?
No, this is the pthreads.library. It's a new implementation, only parts of the old one from os4depot.net remain, it uses the new mutex datatype, and it's part of the standard OS distribution now so there is no need to depend on people downloading stuff.
Quote:
- Apart from the thigs listed (such as shared-object support), are there any other new things developers should know about?
Yes. Stay away from StackSwap().
Quote:
- When can we expect an updated SDK, allowing us to use these new features?
*coughs* When it's done?
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Thanks very much for the update. I'm desperate to use the new features so I'm very much looking forward to the SDK.
I'm afraid that the SDK will take a while. I recently discovered that stripping a dynamically linked binary of its symbol information will cause certain relocations in the binary to be anonymous, so that the resulting binary will crash.
That means that for the next SDK I (or preferably someone with better knowledge of the binutils than me) would need to look into fixing this problem, and possibly updating binutils to 2.17 in the process.
Right now, I am pretty busy with... other stuff.
Quote:
I'm curious does the pthreads library now support explicitly setting a priority of a thread? IE does:
..now return a 0? ..and can it be followed with a:
pthread_attr_setschedparam();
No. pthread_attr_inheritsched will always return ENOSYS.
Same applies to pthread_attr_setschedparam: The threads are nothing more but separate tasks. As such, they are still limited by the exec scheduler, which is fixed to round robin, i.e. you can't set SCHED_FIFO.
One other thing, I've noticed that the installer has an XML file. Can the new installer be used as an installer for other software? If so, will the next SDK include documentation?
Hans wrote: One other thing, I've noticed that the installer has an XML file. Can the new installer be used as an installer for other software? If so, will the next SDK include documentation?
Actually, it's the same installer that is also used for the SDK installation. It can be fully configured via the XML file, although right now, there's no plan to release documentation. It's not an "official" component.
We are planning to do a bit more work on it, like making it possible to embed the archives and assorted files into the binary to make it a "download and double click" installer without the need to unpack to a temporary directory...
Well that installer looks much nicer and cleaner than the standard Installer in the C: directory. The standard installer is definitely showing it's age. Amiga OS 3.5/3.9 had one with some graphic extensions, but it still looks a little dated.
I think it's showing its age because its graphics wasn't updated to use Reaction, that's all.
@Rogue & tfrieden
Thank you for this clarification, especially the StackSwap() is really a "need to know" especially when porting old AOS softs. BTW is the $STACK cookie still ok ?
Also it's sad SDK is delayed further, because it's a long time now since it's been last updated Even a small update with new include and autodocs at least for Final would be good.
abalaban wrote: Also it's sad SDK is delayed further, because it's a long time now since it's been last updated Even a small update with new include and autodocs at least for Final would be good.
Quite..... I've just about given up waiting and I'm having to work around the fact that DMA doesn't work on buffers larger than about 2K.
Incidentally, this post isn't just a *grump*-where's-my-SDK-*grump* posting, but I noticed that I'm no longer getting any serial debug output when I use IExec->DebugPrintF(). Did something change or have I just forgotten to enable something...?
Pleeeease though, new SDK? Even if just enough to deal with the parts that were broken?
Yes its default to a ram buffer, there is command in C: that can dump the memory (C:DumpDebugBuffer), the memory is not lost when doing warm reboot only cold reboot.
In other words you do not need a serial cable anymore, unless you computer freezes up completely.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
You need to add "SERIAL" to the kernel command line. Otherwise, memory buffers are now the default for debug output, and C:DumpDebugBuffers will get you the output.
I am sorry for the delay of the SDK, but one major factor in this is a problem with binutils stripping too much for the shared object support, resulting in unusable binaries when you strip them.
Since my time is limited, and my knowledge of binutils is even more limited, this is dragging on. Just releasing the autodocs and includes will not do much good.
(edit) I am not aware of any problem with DMA with buffers of more than 2k. As a matter of fact, I am very sure that the IDE devices use larger DMA transfers.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Great, that'll help a lot. Debugging a library is very difficult without DebugPrintF!
Quote:
Rogue wrote: @Spirantho I am sorry for the delay of the SDK, but one major factor in this is a problem with binutils stripping too much for the shared object support, resulting in unusable binaries when you strip them.
Since my time is limited, and my knowledge of binutils is even more limited, this is dragging on. Just releasing the autodocs and includes will not do much good.
It's actually just the includes I need. I need to be able to allocate a contiguous lump of memory, approximately 432KB (768x576 - PAL resolution, in other words) and it's impossible without AllocVecTags(). The function's there in the library, I just can't use it without the correct include.
I've found a way of making it use one DMA chunk per line but that means 576 different DMA lists. Yummy. I think a contiguous lump would make life rather easier...
Quote:
(edit) I am not aware of any problem with DMA with buffers of more than 2k. As a matter of fact, I am very sure that the IDE devices use larger DMA transfers.
No, but they're using AllocVecTags() whereas I'm using AllocMem() and hoping for the best as there's no alternative!
It's actually just the includes I need. I need to be able to allocate a contiguous lump of memory, approximately 432KB (768x576 - PAL resolution, in other words) and it's impossible without AllocVecTags(). The function's there in the library, I just can't use it without the correct include.
I've found a way of making it use one DMA chunk per line but that means 576 different DMA lists. Yummy. I think a contiguous lump would make life rather easier...
Darn, I wasn't aware that AllocVecTags wasn't out there yet... that is indeed a problem.
I'll see what can be done about this, but a new SDK is currently not very likely to be released.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Darn, I wasn't aware that AllocVecTags wasn't out there yet... that is indeed a problem.
Why d'you think I've been yelling so noisily about the lack of SDK since January? :)
It means that absolutely no way anyone outside of the people with the Beta SDK can allocate a contiguous chunk of memory - which isn't good for device drivers like I'm writing!
It's actually just the includes I need. I need to be able to allocate a contiguous lump of memory, approximately 432KB (768x576 - PAL resolution, in other words) and it's impossible without AllocVecTags(). The function's there in the library, I just can't use it without the correct include. [/quote]
So large allocvec allocations might be fragmented physically in memory? I didn't realize that; although it's only important when you're writing a driver.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
Even a small update with new include and autodocs at least for Final would be good.
