Talk:Kernel

From S1MP3 Wiki

Dual nature

We are going to have a DSP unit acting like a co-processor and dedicated to multimedia functions, and the main Z80 managing input/output (the application itself that will handle input events, draw shapes/bitmaps, prepare data for the DSP and so on...).

--Legolas558 13:35, 9 May 2006 (CDT)

One question: Why? The DSP is good for signal processing (in our case decoding of mp3/ogg/...) and bad in general processing. The decoding part has to be done independent from the current running ap (if we want to continue playing even if not in the player app) and one app can have multiple dsp files (eg the player app can have a different dsp program for decoding oggs than for decoding mp3s.) I say we just allocate a certain amount of space for music playing dsp-programs; if a program needs bigger dsp files, that can be specified in its header and it'll get linked lower in the ipm/idm-space. - Sprite_tm

My idea was to have the DSP performing other multimedia decoding (like for JPEG and movies), but I got that it is too hard to have "normal" program code in IPM, it would need parallel programming notions. Anyway, this means that we will never have a program (apart from DSPs) bigger than about 10K, right? --Legolas558 12:16, 9 May 2006 (CDT)

Why not? We've got 100K, the biggest codec (Wmadec.dsp) seems to load at most 10K to IDM and 20K to IPM. Let's say there are 10K in DSP buffers etc, that leaves 60K for the program in IDM and IPM alone. Sure, we have to make banking work, but if we do, we can load programs (+api) of many Ks. --Sprite_tm 14:26, 9 May 2006 (CDT)

The fact that remains is that "normal" code cannot be run on DSP :( --Legolas558 15:55, 9 May 2006 (CDT)

About RTDL

We could just load libraries and apps to memory at any random place: the linker would fix up any loose ends. Advantage is that we use as much memory as we need; not less, not more. If we want to upgrade any api we will just arrange a *lib.v2 and make any program which wants to use v2 loading that.

The only disadvantage would be that the object loader would be quite an interesting piece of code. I believe it can be done though; worst case scenario is that if the loader would be huge, we'd just need to load it from flash, so no runtime linking :-(. -- Sprite_tm

Mmm, seems z88dk (or at least the assembler) already can generate position independant code using a stub:

 The principle of relocation is in fact a self-modifying program. You cannot     
 relocate a program that has been blown into an EPROM (cannot be modified). You  
 may only execute relocatable programs in dynamic memory (RAM).                  
                                                                               
 The relocater is built into the Z80 Module Assembler. The relocation table is   
 created during the linking phase. When all object modules have been linked and  
 the appropriate machine code generated, the process is ended with first copying 
 the relocater routine into the executable file, then a relocation table and     
 finally the compiled machine code program. Any defined ORG in your code is      
 superseeded - this is not necessary in a relocatable program!                   

(From: z80asm.txt in the z88dk package, documentation of the -R option) This code doesn't allow the loading of dynamic libraries though, these will have to be statically linked to the .ap file. That will only make a difference in the flash footprint the ap has though, and since we're talking about tens of kilobytes difference on a flash disk of minimal 128 MB, it's a non-issue... Anyway, it might not be what we're looking for, but it at least indicates it's possible. Sprite_tm 12:03, 8 May 2006 (CDT)

Why the granularity of 2K? If we go the dynamic linking way, a program will be linked into a bunch of binary as soon as it gets run, and as long as we don't want to do any linking while an .ap runs (and I don't see why we'd want that... perhaps for some kind of plugin system, but there are other ways to do that too) we can just throw that binary somewhere in memory and be done with it. --Sprite_tm 05:40, 9 May 2006 (CDT)

Yep. Idea trashed. --Legolas558 15:55, 9 May 2006 (CDT)

About RTMM

I'm not sure about that approach... if we 'just' include a complete dynamic runtime linker, the ap doesn't have to be more than an object file itself, preceeded with a header indicating if there are resources in the file that don't need to be immediately loaded to memory and what libraries the program uses. Throw the object file to the dynamic linker, including (from the header) the names of the libraries the program uses, and let the linker figure out the rest. If everything's ok, you end up with just one unresolved symbol: main(). Let the linker resolve that too and you have the entry point of the program. You can then just call that and you're done.

The compiler has to be modified to do a bankswitch, tho, if we want to put our libs in the IPM/IDM. That shouldn't be too hard, however: worst case scenario is that we replace all CALL (addr) instructions that point to an API function to a RET0-instruction, and install a handler in RET0 to do the bank fixup and the call itself.

--Sprite_tm 17:37, 8 May 2006 (CDT)

We are basically saying the same thing, since I was proposing a "custom" .APP format that would allow mixed (Z80/DSP) code in appended blocks. The two concepts of RTDL and RTMM shade one into each other. --Legolas558 17:52, 8 May 2006 (CDT)