![]() The basic skeleton of Main.tu is as follows: With the inner workings explained, I can show you the code and explain the demo:ĭue to the quirks of the stack-based GC, the majority of the code must be encapsulated within a Main procedure. ![]() Thus given two pointers, ptr1, ptr2, if both are higher than the stack_top, and ptr1 < ptr2, then ptr1 is garbage, else ptr2 is garbage. We can approximate this with a variable directly before a function call, like baz in this case. However, to exploit this property, we must determine what the absolute top of the stack (i.e., lowest possible stack address) is so we don't accidentally free a potentially in use variable in the data section of our program. In C, you would do something like this:Īs can be seen, addr(foo) will be at a lower address than addr(bar) (since x86 stacks grow downwards instead of upwards), which means that if a variable is at a higher stack frame, then it is inaccessible. This article aims to demonstrate the furthest limits of the Turing language, with no practical goal in mind. And along with this, did the possibility and idea of a garbage collector begin to form in my head.īefore we begin I'll assume you have a solid grasp of object-oriented concepts, and a solid understanding of pointers and references. I stumbled upon the work of Foundry and his work runtime manipulations of the Turing opcodes were simply amazing. Wow! Coming from a background of C# programming, I did not understand the concept of "clean up your own trash," and found "free after use" quite irritating and annoying. Little beknownst to me, OpenTuring is an object-oriented programming language, which meant that I could store vectors in objects instead of separate components. ![]() A few whiles back, I started on my Game Engine for Turing, along with a preliminary 2D Physics Engine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |