Game Oriented Assembly Lisp: Difference between revisions

Content deleted Content added
No edit summary
rv unexplained deletion by 192.103.152.52
Line 5:
Like many modern implementations of Common [[Lisp programming language|Lisp]], GOAL does not run in an interpreter, but instead is compiled directly into [[PlayStation 2]] machine code for execution. It offers limited facilities for [[Garbage collection (computer science)|garbage collection]], relying extensively on runtime support. It offers dynamic memory allocation primitives designed to make it well-suited to running in constant memory on a video game console. GOAL has extensive support for [[Inline expansion|inlined]] assembly code using a special <code>rlet</code> form[http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html], allowing programmers to freely mix assembly and higher-level constructs within the same function.
 
The GOAL compiler is implemented in [[Allegro Common Lisp]]. It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and therefore running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. The process is similar to the "edit and continue" feature offered by some [[C++]] compilers, but allows the programmer to replace arbitrary amounts of code (even up to entire object files), and does not interrupt the running game with the debugger. This feature was used to implement code as well as level streaming in the [[Jak and Daxter]] games.
 
GOAL's first use was for the original [[Jak and Daxter]] PS2 game; the predecessor language, GOOL, was also developed by Andy Gavin for [[Crash Bandicoot (video game)|Crash Bandicoot]].