Per mention here, I figured it would do to spin off the topic of Prizm SDK organization.

For libfxcg (and thus the GCC Prizm SDK) we have a smattering of include files variously pretending to be either standard C (stdio.h etc) and Simon's FX-9850 (I may have misremembered that number, but meh) derived-SDK (RTC_syscalls.h etc).

First, I find that organization to be hideous, and second, since we have at least three competing toolchain implementations (see linked topic at the top of the post), it would be useful to keep some sort of source compatibility between them.

As for what may be done, I have a few suggestions:
Don't put nonstandard routines in files that share names with standard C libraries.
stdio.h contains the Bfile_* routines in libfxcg, which just serves to muddy the waters. I propose that Prizm-specific routines be placed in an include subdirectory and be given names compatible with those used in Simon's SDK. For example, APP_syscalls.h would be moved to fxcg/APP_syscalls.h. This approach makes it more obvious where unusual-looking library functions come from, and can maintain source compatibility with Simon's SDK with an include path addition (-I $LIBFXCG_PATH/fxcg or such).

Implement C library wrappers
There's been discussion of porting a C library for the prizm, but nobody (read: Jonimus) has been willing to really dig into newlib (or anything else) to really give the port a try. I am of the opinion that we don't need a whole C library, but there are a number of useful routines that we can provide, such as limited portions of stdio (string formatting, for example) and stdlib (particularly to wrap the idiosyncrasies of the Bfile_* syscalls). These would go in the root include directory and fill in the usual standard header files.

There would necessarily be some additional overhead in providing C library wrappers, but that is true of any implementation. For GCC at least, we can mitigate most effects by turning on link-time code generation by default for both libfxcg and the SDK packages (-O2 -flto).

That's all I have to say for now. Thoughts?
I'm willing to put some work into building C library wrappers if there's interest, but the lack of a testing platform puts me at a disadvantage there.

I am in the process of doing just such a cleanup now. And I have spent quite a few hours digging at newlib but I really have no clue what I'm doing here and while it builds and some routines work it seems anything string related just doesn't.

As for the headers I had some plans and I will reply in the morn with them worked out as I just noticed this thread now but I do like your idea of just throwing the simon compatible headers in a separate folder. Though IMO since most of his code for the custom routines he added don't compile under GCC true source compatibility is not possible and I don't have a license or anything from him to include them even if I could get them to build.

Since that compatibility is not possible, at least not completely, my thought was to just throw out the header file naming and create a new organized layout for everything in libfxcg and make it possible to add other libraries without much pain. I have already started some of the reorganizing and pushed some of it to http://github.com/Jonimoose/libfxcg though I have more partial work done locally that has yet to be commited and the makefile for the lib has not been updated to my new SDK layout as I haven't built it in its latest form for Linux where I do my libfxcg work.

I like the idea of completely separating the prizm and other calcs. I also think we need A LOT more documentation than we currently have. I'm probing the OS now trying to figure out how it works, and how it does things, but really, the only wiki I know of is prizmwiki.omnimaga.org.

I'm willing to code and test things. Also, since I've got the build-script set up right, I'd be willing to test stuff with my setup. (Mac os x 10.5..

I'm also okay with documenting stuff if I knew what it did in the first place. Right now, I'm just trying to get my feet wet with C on the prizm, but I don't fully understand how it handles the state of the Add-ins.

EDIT: On that note, I just realized what a bug might have come from!

As I mentioned on HCWP, we have a more organized private wiki that we're gradually building up, and will unveil as soon as it has more content. If we can come up with a set of routines and categories (as in header files), that would go a long way towards advancing the project, and TIFreak8x has been working on and off on the BASIC portion.

I'm still disassembling the OS atm. In fact, /me needs to get back on that now.

Looking at code used in practice, and noticed things like the following:

Code:

I hate that. This stuff still needs cleanup.

Yeah, that one in particular always grates on my nerves. Once we get everything cleaned up, and my semester is over and book draft is written, we should push to get all the ssycalls properly documented on WikiPrizm.

I agree this cleanup is needed, and I'll happily accept patches or zips of the headers and such from anyone willing to do it, I just personally don't have the time or the energy to do so atm. Near 12hr workdays do not leave much energy for personal projects. :/

Edit: Heck I can give anyone interested in doing the work commit access to the main repo if they prove themselves trustworthy and everyone agrees on the plan for how things should be done. IIRC Tari already has access to the github repo.

I started cleanup, staging it on bitbucket since Git is a gigantic pain to use on Windows.

Phase I is removing all the redundant definitions and pushing system-specific things into the 'fxcg' subdirectory, then rearranging the headers to be more logical and renaming some things to clutter namespaces less.

My current thought on supporting the mini-SDK headers (the hated keyboard.hpp...) is to just create a 'compat' directory which contains all of the old (nasty) headers, for those programs that are no longer maintained. Everything else should migrate to the new structure.

To be honest, I wouldn't even object to wiping out support for the old mini-SDK headers, since I think relatively few people (certainly no one at Cemetech, and I don't think any Omnimaga-only people still do Prizm work) use Simon's mini-SDK.

I do.
I would like to switch to something else, because I prefer C over C++ for such small devices and this SDK doesn't support C, so I have to #include C files into CPP, which is ugly.

I agree, but that still leaves any programs that nobody can be bothered to update. On the other hand, nobody willing to change a few headers around probably means nobody really cares at all. It's all in version control, so I suppose one could always check out an old revision to build against. In any case, I think the changes should be documented.

How is including C files in CPP ugly? It's all compatible- going the other way is much nastier.

Wasn't someone (I don't recall who, offhand) doing some work in C++ on the Prizm? I don't think we have libstdc++ (but perhaps we actually do, I haven't actually looked into it), but even so, that doesn't preclude you from using the language's OO features.

I think I'll need to make some changes to the existing headers (#ifdef CPP \ extern "C" {), but giving C++ first-class support should be easy.

I was working on a game using C++ and g++ works well. extern "C" works well.

Since we don't really have a thread for libfxcg, I'll just note here that I set up a build bot, which should make it easy for people to stay on top of the changes.

http://www.taricorp.net/libfxcg/

Thank you! Hopefully this will save me the hassle of compiling the latest GIT just to be able to use the PowerOff syscall and not have assembler errors. But I see the next build is scheduled to happen in almost 10 hours... so that means I'll only resume development tomorrow or later

I still need to configure the compiler on the build slave, but I'll see about forcing a build as soon as it's set up.

Turns out there's no way to make buildbot create packages after running a build, so I wrote a quick script to automate the build process.

The libfxcg Makefile was also rather broken (it made an empty archive since it seems things have moved since it was last used), so I fixed that. I'll now be generating nightly tarballs, available for download:
http://media.taricorp.net/libfxcg-latest.tar.bz2
The logfile from the build is also there, in case something stops compiling:
http://media.taricorp.net/libfxcg-latest.log

I just updated libfxcg in order to be able to use PowerOff, but it seems this new build lacks memcpy, malloc and free - or else my code, which compile perfectly before has something wrong.
I did not replace the "include" folder with the one in the tarball, as that resulted in even more compile errors (which I can post if you want).

Right now, replacing libfxcg.a for the new one and not replacing the "include" folder, the build result is this: http://pastebin.com/ND0iR36k

EDIT: after replacing the "include" folder and moving some files from the old one, I could make it stop complaining about the code in the includes, but then it outputs the same errors as on the pastebin above.

Should be fixed in git, and there's a new build up.

The syscalls for malloc, free and friends were exported as sys_malloc, etc. I just changed those definitions, since there's little reason to annotate that they're syscalls (right now, at least).

Note to self: provide prototypes for C90 and C99 builtins, per discussion here.