#154392 - Lazy1 - Tue Apr 15, 2008 4:57 pm
So I decided to re-port sdl-sopwith with the intention of doing a much better and cleaner job than before.
I got sound working yesterday but I'm 99% sure my shared memory IPC will break horribly when devkitARM gets upgraded.
What is the ideal way to go here?
Should I wait until better IPC methods become standard or keep using shared memory and update my code later?
#154405 - tepples - Tue Apr 15, 2008 7:51 pm
Isn't there a way to install two copies of devkitARM on a PC, one kept updated and one not updated? I'd like to know too.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#154406 - simonjhall - Tue Apr 15, 2008 7:55 pm
Before upgrading I just take a copy the entire devkitpro directory. If I have problems, I just revert to the old one. Easy money...
_________________
Big thanks to everyone who donated for Quake2
#154409 - silent_code - Tue Apr 15, 2008 8:42 pm
in code::blocks, i have different compiler sets i can choose from (an create). so i could, in theory, have two isolated installations without collisions. and no environment variables needed (can be set in c::b). ok, i *have* two sets of gcc installed, one for win32 and one for arm/nds.
for me it's just a matter of tools. :^)
ps: i was a hardcore shell user (not neccessary knowledge wise, but in usage frequency)... and i still wouldn't touch eclipse (no offense!)
#154413 - simonjhall - Tue Apr 15, 2008 10:54 pm
What does this change in IPC mean anyway? As in the IPC struct that's used to move the pen position etc from CPU to the other is going to be changed, or is it something like the FIFO is going to be always in use or something?
_________________
Big thanks to everyone who donated for Quake2
#154415 - silent_code - Tue Apr 15, 2008 11:18 pm
afaik, things are going to be handled by the fifo.
#154419 - yellowstar - Wed Apr 16, 2008 1:10 am
| Lazy1 wrote: |
I got sound working yesterday but I'm 99% sure my shared memory IPC will break horribly when devkitARM gets upgraded.
|
So dka22 is going to not allow anybody to even use shared memory, or at least screw anything using shared memory?
#154424 - eKid - Wed Apr 16, 2008 2:16 am
| Quote: |
| So dka22 is going to not allow anybody to even use shared memory, or at least screw anything using shared memory? |
You can still use shared memory:
You just need to:
1) allocate memory
2) pass pointer through FIFO
#154425 - elhobbs - Wed Apr 16, 2008 2:19 am
I suspect it will only break shared memory if your implementation uses the IPC struct or is tagged unto it - just a guess though. I seam to remember a few threads with certain people getting quite upset whenever someone released a lib that referenced the IPC struct.
#154426 - yellowstar - Wed Apr 16, 2008 2:26 am
Good. I was wondering about Juglak's WMB Host, since it uses shared memory.
#154493 - wintermute - Thu Apr 17, 2008 12:07 am
| yellowstar wrote: |
| Lazy1 wrote: |
I got sound working yesterday but I'm 99% sure my shared memory IPC will break horribly when devkitARM gets upgraded.
|
So dka22 is going to not allow anybody to even use shared memory, or at least screw anything using shared memory? |
This has nothing to do with devkitARM, nothing in the toolchain is particularly DS specific.
devkitARM release 22 will change nothing that will affect any aspect of the DS libraries.
The next release of libnds will take place after devkitARM r22, after that the use of shared memory for interprocessor communication will be deprecated.
| elhobbs wrote: |
I seam to remember a few threads with certain people getting quite upset whenever someone released a lib that referenced the IPC struct.
|
People are being given advice not to depend on the IPC struct, it *will* be deprecated and removed. This is called fair warning, it's nothing to do with being upset.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#154507 - elhobbs - Thu Apr 17, 2008 1:39 am
| wintermute wrote: |
| elhobbs wrote: |
I seam to remember a few threads with certain people getting quite upset whenever someone released a lib that referenced the IPC struct.
|
People are being given advice not to depend on the IPC struct, it *will* be deprecated and removed. This is called fair warning, it's nothing to do with being upset. |
sorry if I offended, I was really just trying to point out this topic has come up a few times before while not naming names. In any case thank you for all of the work you do on devkit/libnds. It not only makes homebrew development for the DS possible, but also fairly painless. Thank you.
#154520 - simonjhall - Thu Apr 17, 2008 7:46 am
| wintermute wrote: |
| The next release of libnds will take place after devkitARM r22, after that the use of shared memory for interprocessor communication will be deprecated. |
What exactly does that mean? And how will it become deprecated? I've never touched the IPC struct, I don't use the FIFO but I do use shared memory (allocated via malloc) in my programs.
What will this mean for me?
_________________
Big thanks to everyone who donated for Quake2
#154527 - elhobbs - Thu Apr 17, 2008 1:43 pm
it is only an issue if it uses the IPC struct which wintermute said will be depreciated and removed.
#154528 - wintermute - Thu Apr 17, 2008 1:53 pm
| simonjhall wrote: |
What exactly does that mean? And how will it become deprecated? I've never touched the IPC struct, I don't use the FIFO but I do use shared memory (allocated via malloc) in my programs.
What will this mean for me? |
I don't really understand your question. How are you using shared memory without FIFO or the IPC struct?
One of the major features added to libnds is a FIFO communciation layer and API. The intent is to provide a default arm7 core which provides most features the average homebrewer is likely to need and reduce the need for writing custom code. This, in turn, will allow us to produce better dswifi examples without the need to maintain many examples including a custom core.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#154530 - simonjhall - Thu Apr 17, 2008 2:23 pm
| wintermute wrote: |
| One of the major features added to libnds is a FIFO communciation layer and API. The intent is to provide a default arm7 core which provides most features the average homebrewer is likely to need and reduce the need for writing custom code. |
Kewl, that sounds fab. Will stuff like text printing and the like be made available through this?
_________________
Big thanks to everyone who donated for Quake2
#154680 - tepples - Sun Apr 20, 2008 7:55 am
| wintermute wrote: |
I don't really understand your question. How are you using shared memory without FIFO or the IPC struct?
One of the major features added to libnds is a FIFO communciation layer and API. |
So as I understand it, programs that used to send a pointer to shared memory through the IPC struct can be trivially updated to send the same pointer through the FIFO, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#154910 - nutki - Tue Apr 22, 2008 9:40 pm
| wintermute wrote: |
| People are being given advice not to depend on the IPC struct, it *will* be deprecated and removed. This is called fair warning, it's nothing to do with being upset. |
Will you modify linker scripts to include last 4k of memory in the heap when removing IPC struct? I vote for leaving it as is. I know that using this memory can be replaced by IPC queue, but it would be easier to port existing apps.
Edit: Speaking of linker script. The DTCM is defined to be 16k in length and the stacks in negative offsets from dtcm_end. This allows full 16k to be allocated in C code using section(".dtcm") and trashing stacks / interrupt vectors in result. Is this considered non issue or I am doing something wrong.