Although there hasn't been many updates to the project site, or to the project releases, on SVN there has been lots of activity. The reason for not coming up with a new release with the top notch SVN is that most of the changes on SVN I already had patched for MinPSPW. This isn't all, latelly I've been working on getting the toolchain to build under windows vista, and I'll start soon on Windows 7. To the upcoming release there will be a new assembler in order to fix the issues binutils 2.16 where having on linux builds and I hope to finish soon a cool plugin for eclipse, so it will be even easier to get started with PSP development.

As minor features, the upcoming MinPSPW will include gcov support so we can do code coverage, binutils 2.18 so we can link faster and with less bugs, and eclipse plugin so we can focus in game development instead of pluging the tools together.

The work on the build scripts have stabilized at the moment the same script is able to build the SDK on Windows, Linux Ubuntu and OpenSolaris 2009.06. You can now enjoy the latest SDK on any of these Operating Systems with the extra benefit that they will all behave the same way.

The current build includes the latest SVN and now is updated to include even more devpaks (38 in total):

zlib
bzip2
freetype
jpeg
libbulletml
libmad
libmikmod
libogg
libpng
libpspvram
libTremor
libvorbis
lua
pspgl
pspirkeyb
sqlite
SDL
SDL_gfx
SDL_image
SDL_mixer
SDL_ttf
smpeg
ode
libpthreadlite
cal3D
mikmodlib
cpplibs
flac
giflib
libpspmath
pthreads-emb
tinyxml
oslib
libcurl
intrafont
Jello
zziplib
Mini-XML

Don't panic! This doesn't mean I won't support windows, it means that is getting more and more cross platform. I've been updating the toolchain and am happy to announce that for the next release there will be a set of Visual Studio projects you can add to your installation, so no need to setup by hand (thanks to Lukasz Przytula).

And now the drop of the W, for the next release I will release the same SDK for Windows, Linux (ubuntu) and OpenSolaris.

Stay tuned for the upcoming release...

For the last months I've seen people fighting to get the SDK to build and run properly on Linux. Although I'm doing these patches and builds for Windows, Linux has always been one of my major development environments. I've been using Linux (and literaly burning laptops) since the good old days of 2.4.18 (before I was only checking it out).

As a development platform I was always more productive with Windows therefore my porting experience, however after using XP for years and years and not willing to jump to Vista and to 7 (well, at least for now...). I've installed Linux on a spare laptop and decided to get my PSP development going on from there too.

I decided for Ubuntu mostly because of the hype and second because I've always been a fan of Debian (although they are a bit to strict with licences...). I tryed to install the SDK with the stock scripts and... they were broken didn't work, there were errors, segfaults, etc.

So during my last weeks my task has been to update my windows scripts to work also on Linux and finally I got my first build. It contains:

• binutils 1.16.1
• gcc 4.3.3
• newlib 1.17
• zlib
• bzip2
• freetype
• jpeg
• libbulletml
• libmad
• libmikmod
• libogg
• libpng
• libpspvram
• libTremor
• libvorbis
• lua
• pspgl
• pspirkeyb
• sqlite
• SDL
• SDL_gfx
• SDL_image
• SDL_mixer
• SDL_ttf
• smpeg
• zziplib

I still have to fix the other DEVPaks scripts that are broken (almost 20) but these work. The main advantage over the official scripts is that you do not need to downgrade your compiler to get it around the binutils bug.

Now have fun and get it here.

This is a minor update to help the users of the latest Eclipse which found a very bad bug with the release of CDT 5.0.2.

In this build there is an option to install gcc alias to the native gcc.exe and g++.exe in order to get it working with Eclipse.

Get it here!

To celebrate almost one year of development the book has also been updated and more stuff is covered including the fix for this "broken" Eclipse.

Get it here!

I haven't created new local projects in my Eclipse for a while but always try to keep it up to date, and today, I was shocked! I couldn't use the discovery features from Eclipse with my custom GCC builds for the PSP.

Aparently the latest CDT removed the option to specify the discovery command, which is not that of a big deal except when you really want have full code completion for libc, libc and other header files.

There is a hack however! Open your PSPSDK\bin directory and copy the psp-gcc.exe to gcc.exe. Don't rename, copy it, this way Eclipse will pick the right configs again.

Pay special attention to the fact that if you have another gcc.exe in your path this might interfere and your configuration can get all messed up.

While you are waiting for the next release of the MinPSPW project you can have a look to the very alpha alpha alpha draft of my "PSP Development with Eclipse" eBook.

Don't expect much right now, this was my first attempt to dump the basics of setting up the environment and debug a sample application with Eclipse visual IDE and the MinPSPW SDK. I am assuming that there are lots of grammatical and composition issues since I haven't really reviewed this yet.

One of the Objectives of the book is to cover the topics:

• Install MinPSPW
• Install Eclipse
• Install Blender + Python
• Code a simple Application
• Debug the Application from Eclipse
• Deploy from Eclipse to the PSP
• Write a Simple 3D exporter
• Wrap Up and render your Blender content on the PSP

At the moment only the Installation and debug is covered but with time it will expand...

This is the first stable release of the 0.9 series. 0.9.2 includes a couple of new improvements:

• Newlib 1.17.0
• new C99 wide-char function additions
• movement of regex functions from sys/linux directory into
• shared libc/posix directory
• string function optimizations
• redesign of formatted I/O to reduce dependencies when using
• sprintf/sscanf family of functions
• numerous warning cleanups
• various bug fixes
• Patched SDK for missing functions (only declared on the ASM side)
• GDB works with the Slim (wasn't reading the correct memory address if the variables where above 0x0A000000)
• Added exception support to C++ samples

Get it here.

On this series I've updated the newlib (again) from 1.16 to 1.17 and there is a patch for gdb under the slim. On those PSPs when inspecting variables outside the lower bound of the memory the gdb wasn't receiving the correct value, now, thanks to Tyranid, it can!

GCC has been updated to 4.3.3. The only major update is:

• GMP updated to 4.2.4
• GCC updated to 4.3.3
• SDK updated to latest SVN

Still a minor release, update if you need the latest GCC

I've been busy with a couple of things lately, first reading Haiku GCC patches to support threading and trying to understand the mess that is binutils source code.

Why threads on gcc? well basicaly because... C++ would get exception handling and Objective-C better performance. This might sound weird but that's some funky libgcc stuff that is not working for the PSPSDK.

Binutils on the SDK is getting old, we are 3 versions behind so we need to update or we might get problems in the future. One would be that the SDK would get stuck with an old GCC version.

Today I was asked why I am so interested on the LLVM, maybe still related to the Java is evil! So they say.... Well first things first LLVM is a VM but not exactly in the Java VM sense. In fact it runs bitcode, not bytecode. Bit code is some sort of high level assembly but what makes is interesting is:

1. Traceability in translation
2. Transparency in translation

Let me extend this. The fact that the same LLVM compiler can build both the native objects (ELF x86|MIPS|M68k|.../PE x86) and its own low-level representation (bitcode) of that in LLVM-space, means you have a direct chain of causality, and traceability, back to the compiler front-end which was responsible building the meta-models of the source code, for translation, at t = 0.

If you needed to map a symbol in either translation (object vs LLVM) back to the source code, you can do that, with the appropriate markers. This is going to make a big difference to their time/people costs re maintaining LLVM just in simple, shop-floor, "dirty hands" engineering terms.

For the second point, Whilst gcc does compile to its own intermediate representation, this has never been a "lingua franca" (in 4.4 it seems they are changing it again) for optimization tools to communicate -- e.g. you can't simulate L2 cache fetches easily from it, or do coverage analysis. The job of intermediate representation is limited -- it is oriented towards the GNU assembler only, and only for the generation, not the analysis, of code in the higher level language you're working in.

LLVM changes this, by making it possible to translate source to LLVM bit-code, a transparent representation which in [1] you can trace directly back to the original source code.

There's a co-dependency of [1] with [2] here. Transparency in translation only becomes useful if you can trace the product back to the source. And on the other hand, traceability in translation is only truly possible if you have a *transparent* and easily understood representation which analysis tools can use too.

So lets look on how to compile some bitcode to any platform (supported by LLVM), I'll start with the simple Hello World:

First of all llvm is just a bitcode compiler, it assumes you have a frontend that will translate the code from your favourite language (and yes you can get a frontend for java) but llvm comes without any so lets go low level to bitcode:

; Declare the string constant as a global constant...
@.LC0 = internal constant [13 x i8] c"hello world\0A\00"          ; [13 x i8]*

; External declaration of the puts function
declare i32 @puts(i8 *)                                           ; i32(i8 *)*

; Definition of main function
define i32 @main() {
    ; Convert [13x i8 ]* to i8  *...
    %cast210 = getelementptr [13 x i8 ]* @.LC0, i64 0, i64 0
    ; Call puts function to write out the string to stdout...
    call i32 @puts(i8 * %cast210)
    ret i32 0
}

As you can see bitcode is not like x86/MIPS assembly, it is quite readable and even support high level functions, structures and garbage collection. Once you have this hello world you can save it to a file called hello.ll.

Now the major difference to say gcc is that one compiler can compile for all platforms (with gcc you need a specific cross compiler for each platform). In a Lord of the Rings way, LLVM is a compiler to rule them all.

So lets compile this hello world for my x86 32bit machine running windows. To do this like with normal assembly one needs to assemble the bitcode and link to the crt lib. With LLVM you achieve this by running:

llvm-as hello.ll

Optionally you might want to optimize your assembly, then you can do it running the optimizer:

opt hello.bc -o hello.opt.bc

In this example the optimizer won't to anything since the code is already optimized. Now lets run the bitcode with the LLVM JIT:

lli hello.bc
hello world

As expected you see the amazing string "hello world". Now the impressive thing is, what if I wanted to run this natively on widows:

llc hello.bc
gcc -c hello.s -o hello.o

And run the same on my PlayStation Portable:

llc -march=mips -mcpu=allegrex hello.bc
psp-gcc -c hello.s -o hello.o

Well what is so impressive one may ask. The impressive detail is that the same assembly is translated to x86 optimized assembly (in the first case) and to MIPS assembly on the second. We all know that x86 is a CISC architecture and MIPS a RISC architecture making fundamental changes on the assembly commands and code. LLVM simplified this by making unique.

This new release contains an updated newlib to 1.16 and a basic set of devpaks for most users:

• zlib
• bzip2
• freetype
• jpeg
• libbulletml
• libmad
• libmikmod
• libogg
• libpng
• libpspvram
• libTremor
• libvorbis
• lua
• pspgl
• pspirkeyb
• sqlite
• SDL
• SDL_gfx
• SDL_image
• SDL_mixer
• SDL_ttf
• smpeg
• zziplib

Also the ObjC sample was fixed and now it really says hello on the PSP.

Planning:

• For the next release I am planning to reduce the static lib file sizes by striping the debug information and replace the nodoc installer by a basic installer without docs, samples and only C/C++ support
• I've run the SDK against splint and I got a few warnings that should be fixed to make the SDK a more stable package.
• Add some simd library to take use of the VFPU without codding directly in ASM (in the style of libpspfastmath)

The latest SDK is out, this release features, the full Objective-C, Objective-C++ compilers and runtime, cleaned Documentation and smaller, less bloated installer.

One of the complains I was getting from the PSP SDK was that it's binaries were too big compared to the previous version, that was true. The reason was that I was compiling the whole SDK with -G0 option, however that option is not really necessary except for Objective-C.

After digging into it I patched the GCC build scripts and now only libobjc is built with that option.

Also I am planning a new update SDK that builds without documentation errors, until now, I just generated the documentation and didn't bother to see if it was good and if there were any errors/warnings coming from doxygen, well... now I did, I fix them and next SDK will be even better.

Also I am planning to strip the binaries at compile time instead of running strip as a second step, I'm still undecided if wheater or not I should do the same with the built in libraries, this would mean that the libs were smaller meaning smaller assemblies more proper for release mode... maybe I can add a optional installation step to replace the original libs with the stripped ones... For example the libstdc++ will take 1.5Mb instead of 5Mb...

Finally I tried without success to update binutils from 2.16.1 to 2.17, I managed to merge all the changes but the assembler doesn't work, I guess I really need to look into the code instead of just trying to apply the patch.

After one week of research I managed to get Objective-C to work with the PSP toolchain. If you like this alternative to C++ and very lightweight you can make applications like this on your SDK 0.8.8:

#include <objc/Object.h>

@interface Greeter:Object
{
 /* This is left empty on purpose:
  ** Normally instance variables would be declared here,
  ** but these are not used in our example.
  */
}

- (void)greet;

@end


#include <pspkernel.h>
#include <pspdebug.h>
#include <pspctrl.h>

/* Define printf, just to make typing easier */
#define printf  pspDebugScreenPrintf

@implementation Greeter

- (void)greet
{
	printf("Hello, World from Obj-C!\n");
}

@end

/* Define the module info section */
PSP_MODULE_INFO("template", 0, 1, 1);

/* Define the main thread's attribute value (optional) */
PSP_MAIN_THREAD_ATTR(THREAD_ATTR_USER | THREAD_ATTR_VFPU);

int main(void)
{
	id myGreeter;
	myGreeter=[Greeter new];

	[myGreeter greet];

	[myGreeter free];

	/* Non Objective-C code to allow the app to end */
	SceCtrlData pad;
	
	printf("\nPress X to quit.\n");
	for (;;)
	{
		sceCtrlReadBufferPositive(&pad, 1);
		if (pad.Buttons & PSP_CTRL_CROSS)
			break;
		sceDisplayWaitVblankStart();
	}
	sceKernelExitGame();
	
	return 0;
}

I am planning to rewrite all the devpak scripts to work on linux. I've noticed that I've some problems because I am using uuencode and uudecode and you need to install a sharutils package. I'm digging into otherways of doing this like SUN jdk installation bin file for linux...

Finally almost 1 month after the SDK 0.8.7 is out with GCC 4.3.2. It took so long because I messed up my Msys/MinGW installation. Installing Msys is all but trivial, all packages seem to fit together but once you start using then some versions do not like other and is a mess. I now have it stable and am back to business. I also re wrote the toolchain script which lead its length to be almost 50% smaller and more readable.

If someone has been paying attention to the project SVN, there are less and less patches. This means that my changes are slowly being added to the main toolchain SVN repository. At the moment, I only hold 2 patches, one to the new lib to allow uint32_t and int32_t to be an alias for int and not long (personal taste). And another to make it work under a DOS command line.

I'm busy now trying to get it to work under the bleeding edge GCC 4.3.2...

• DEVPAK
• Experimental
• LLVM
• SDK