Console Development – The Last Month

December 11, 2008

Filed under Console Development
Tags: Computer, Console Development, Games, Programming

leave a response

So, Console Development lectures for the last few weeks have all been of the same format, we have been put into groups of 3 people and we have been told to go away and find out as much as possible about a certain topic. We then had to present the results of the findings to the rest of the teams and the lecturer via any means we wished. Here is what we have been up too for the last 4 weeks:

Team Presentations

Creating a Program

The first task as part of the group was a basic task which was to create a basic program that will run on the PSP Development Kits that we have scattered across the labs, the basic program had to link between 3 different files. I was self appointed team leader, which was quite a vague title but it just meant that as well as making one file for the program i also made the MakeFile, which is a file used to call the compiler with some special flags that we had set and with a name we had provided. The program that i decided we make is a basic program that inside a loop calls 2 functions, one being the Computer and the other being the PSP and they have a conversation between each other as the index of the loop is passed to each function.

As stated before i also had the task of creating the MakeFile, i took this quite far and started picking apart the MakeFile that was given to us in an example piece of code. I picked it apart finding out what each flag did, whether it was needed or not to actually make our program compile the makefile was also doing quite a bit which was not written down, its given for granted that it does it automatically, but for extra clarification i also wrote out the bits of the makefile so that i could explain it slightly better during the presentation. The final MakeFile is as follows:-

#
# Conversation Makefile
#

FLAGS = -W -Wall -g -c -o
TARGET = Conversation
OBJS = main.o hello.o world.o

all: $(TARGET).prx

clean:
rm -f $(TARGET).prx *.o *~ *.bak

$(TARGET).prx: $(OBJS)
psp-gcc $(OBJS) -startfiles -o $(TARGET).prx

main.o : main.c
psp-gcc $(FLAGS) $@ $^

hello.o : hello.c
psp-gcc $(FLAGS) $@ $^

world.o : world.c
psp-gcc $(FLAGS) $@ $^ ($@ and $^ refer to the file to be created and the dependencies)

The above is how our MakeFile looked, the declarations at the top are basically templates so that when that it said anywhere else in the file the right hand side will get put in place.

The all: and the clean: functions and all the other red coded parts can be called from the Cygwin Bash Shell, which is basically a command prompt that simulates a Linux environment on Windows, if you just type ‘Make’ it calls the make file which is set by default to all: if you type ‘Make clean’ in the command prompt then it calls the clean: function and so on.

If ‘Make all’ or just ‘Make’ is called it will try to create $(TARGET).prx, which is Conversation.PRX, to create this file it looks down to the $(TARGET).prx function and the $(OBJS) next to that are the dependencies for the .prx to be made, without the ($OBJ) files there it will not create the .prx, so before it creates the .prx it must first create the .o files, which it then looks down the rest of the MakeFile and it creates them as it goes, finally giving out the compiled Conversation.prx which can then be loaded onto the PSP.

The Programs Memory Allocations

We then had to run the program in the PSP De-bugger and find out about where the variables were stored in memory and how different types of variables refer to different types of memoy:

• Static Memory Allocation – Global variables, they stick though the entire programs running and get deleted at the end of program execution – Therefore are stored in the program data.
• Dynamic Memory Allocation – When ever memory on the heap is being allocated at run time, such as using the new keyword in C++ or Malloc in C.
• Automatic Memory Allocation – Local variables, they are stored on the stack and pushed onto the stack when created and poped when the function it is local too is finnished.

 

We had to do a presentation on this to the other class members once again. This time we made a small powerpoint to explain what we found, the findings we made we as above.

We also had to modify our program slightly to get a better presentation to give, we had to create a global variable somewhere as we only had Local variables at the moment. We also tried to use the new Keyword, then found out it did not work and we needed to use malloc() in C.

Optimisations

Using the flags -O0, -O1, -O2 and -O3 we had to find out the differences between what each flag did, we set up some runtime profilers in our code and found out what they were. We also made a few comparisons with the assembly code that was created as the optimiser sometimes changed the code dramatically!

The main findings we came away from the presentation with were that the different levels of optimisation do not have lots of change on the small program we created, there was a visible but only slightly change to the speed at which is took to run the code but a slightly larger file size and longer compile times as a result.

The Lectures

The lectures that we have been having have been talking more about the inner workings of the computer, talking about the computer architecture and how this relates to the PSP that we will be working with for the next year.

Intro to PSP Development

We first went into an introduction to PSP Development, to get us ready for creating the program above, this took us though a tutorial in our teams that taught us how to create a basic program and how to navigate and call things through the Cygwin Bash Shell, which as i mentioned before is a program that tricks Windows into thinking its running on Linux, and the command prompt can be used to compile programs and view files etc.

Toolchains and Linking

The next thing we looked at were toolchains and linking, how the files get compiled and linked. They start of with a PreProcessor which moves all of the #incudes and macros and such into the correct positions into the file, for example if you #Include and header the whole contents of the Header file are placed into the .c. After the PreProcessing stage then comes the compilation stage, which is a stage which converts the .c into assembly language that is readable by the platform required, in our example we compile the program to be ran on the PSP so the compiler compiles MIPS Assembly code. After compilation stage then comes the assembler stage, which outputs machine code which can be read by the machine, at this point it can still have some unresolved externals that it is yet to know. The final stage is linking, which links all files, resolves all unresolved externals and outputs a loadable file.

Performance Fundamentals

We then went on to talk about Performance Fundamentals and how we define performance in computers. This can be effected by three factors, the Instruction Count, which can be changed in software by us, the programmers, by laying out our code better, using better algorithms and such. The second factor is the Clock rate of the processor, which is a hardware problem and for a single computer can not be changed (unless you want to risk overclocking and blowing it up). The final factor is the CPI, or Cycles per Instruction, which an average of the cycles it takes to execute a set Instruction Set. This can be changed by the programmer but is also affected by the Hardware.

Pipelines

Here we talked about the Pipeline Architecture and how it can be split up into 5 separate parts, the Instruction Fetch, Instruction Decode and Read Registers, Execution and Address Calculation, Data Memory Access and Write Back. To improve the time it takes to execute these parts of the Architecture each of the 5 parts can be worked on at the same time, passing 5 instructions through the pipeline at once. This is known as Pipelined Microarchitecture and it is used it most computers today. If each one of the 5 stages were to take 1 clock cycle there would be an instrction completed each clock cycle! There are a few hazards which can be created by working in this way though, you could be reading an out of date memory value or register value as the instruction before it is working on it at the time. Also if a branch or jump instruction is called then it takes 3 cycles before it knows the outcome of the jump, meaning if it did branch the instructions after the branch would be useless and need to be flushed.

Cache

In this weeks lecture we were discussing the cache and the speeds of the different memory area’s, as well as what is meant by a Cache Hit and a Cache Miss and what implications these can create.The purpose of a Cache is to copy values to a fast local store so that the processor can work on them much quicker as it takes 100 times less speed to work from cache as it does working from main memory. But what data gets fetched? Well this is where the Principle of Locality comes in, it will fetch either huge blocks of memory at a time by thinking that memory usually runs linearly so it would copy the needed value and the values from its neighbours in memory back into the Cache, this is called Spatial Locality. The other Principle of locality is Temporal Locality which would try to keep recently used items in the cache, such as loops, if a counter is used that would be stored as it is used each run though the loop.

After talking about the Principles of Locality we went on to talking about Cache hits and misses, there are two types of cache hit and cache miss, these are created when the cache tries to find data it needs in the cache while reading the data, if  it does this is a read data cache hit, if not its a miss. The other is when data is trying to be written, if the data is in the Cache then it is a cache hit, if not, a cache miss. The aim of all programmers is to try to get as many cache hits as possible, as if there is a cache hit reading data can be done without stalling the pipeline and writing can be done with minimal stall. If a Cache miss occurs then a major stall is created in the pipeline, depending on how it is set up the Cache will respond to misses in different ways.

That marks the end of this Blog post, and the end of Console Development for Semester 1, next week is used for the other 2 modules which i will blog about soon and keep you updated as the deadline approaches!