[teklib-general] A question about "TInitVectors"
Timm S. Mueller
tmueller at neoscientists.org
Fri Dec 18 17:54:40 CET 2009
On Fri, 18 Dec 2009 23:13:57 +0800
Chunlin Zhang <zhangchunlin at gmail.com> wrote:
> I am reading code of teklib,and found some codes I can not understand:
>
> "
> TLIBAPI void TInitVectors(struct TModule *mod, const TMFPTR *vectors,
> TUINT numv)
> "
>
> in "TInitVectors" it just copy each of vector item to mod,but why copy
> to "struct TModule" ?
> Could it be that when using "mod" it will be change to "TMFPTR *" to
> use,not "struct TModule" ,is it?
Yes. Remember, the layout of a module in memory is this:
____________
negative | | --> mod_func[-N]
size | function | --> ...
| table | --> mod_func[-2]
base ____ _|____________|_ --> mod_func[-1]
address | |
| module |
| header |
positive |____________| module
size | | base
| module |
| specific |
| data |
|____________|
Pointers are normally of the type of data that is starting at a given
address, not of the type of data that is located in front of it. Also,
we expected the programmer to have a pointer to struct TModule * handy.
Technically, it could have been TMFPTR (or a void * pointer), because
it is casted anyway inside the function. This is just a cosmetic issue.
> And another question,is it possible to port teklib to a operating
> system which have not POSIX API.I want to port teklib to a feature
> phone platform,which even have not full C runtime lib support(it have
> its own memory/filesystem api),is it possible?
Yes, this is definitely possible, and this is what TEKlib has been
designed for in the first place. We created some ports for platforms
without an operating system, like the Playstation 2. There we had no
working memory allocator, and the rest of the C library was so
fragmentary and broken that it was of little use.
The following files need to get ported:
src/teklib/<platform>/host.c - platform-specific startup
src/teklib/<platform>/main.c - platform-specific entrypoint (main)
src/hal/<platform>/hal.c - Memory, mutexes, signals, threads, etc.
Then you will probably need I/O drivers. If you have something remotely
resembling standard I/O or a filesystem, you may want to implement a
device driver:
src/io/<platform>/iohnd_default.c
src/io/<platform>/iohnd_stdio.c
But you are free to implement only a small subset, like we did in
io/ps2/iohnd_ps2io.c.
> If possible,can I get a guideline of how to do that?
Unfortunately, there is currently no written tutorial, and the source
code is all we can offer. If you have specific questions, I will try to
answer them.
- Timm
--
Timm S. Mueller <tmueller at neoscientists.org>
More information about the teklib-general
mailing list