no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | cybiko:featuressdk [2009/11/27 17:54] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ======Possibly faulty function - get_safety_pool_size====== | ||
+ | The get_safety_pool_size() function claims to return the size of the maximum memory pool that can be allocated. However, during testing with the Pro Version of the SDK, this call always seems to return 0. | ||
+ | |||
+ | ======Known Memory Leak====== | ||
+ | "There are several known memory leaks, but the only one they admitted to was | ||
+ | calling exit() from within a C program terminates the thread and leaves the code segment of the running application in memory creating a memory leak of up to 64K" | ||
+ | (reported on cydevr.net by Greg Smith) | ||
+ | |||
+ | ======main.e - what is this file?====== | ||
+ | |||
+ | According to some notes in the Pro compiler helpfile changelog, main.e is the bytecode interpreter bootstrap code. This file gets included into any applications .app archive. So, now we know. Interesting to note that if the ' | ||
+ | |||
+ | ======Inline assembler====== | ||
+ | |||
+ | As in gcc, it is possible to ' | ||
+ | This also works with the cybiko vcc1 compiler, but is not documented in the Cybiko SDK helpfile. | ||
+ | Simply use the construct / | ||
+ | This will be included, verbatim, in the assembler file which is emitted by the compiler. | ||
+ | |||
+ | |||
+ | ======The ' | ||
+ | |||
+ | This is an interesting feature of vcc1. If we insert a line in the C source // | ||
+ | |||
+ | 1. a ' | ||
+ | |||
+ | 2. the assembler code ... | ||
+ | |||
+ | .ln nn 4 - where nn is the line number of the label() call. | ||
+ | | ||
+ | push | ||
+ | | ||
+ | | ||
+ | |||
+ | The ' | ||
+ | Will have to work out exactly what this is all about, later. | ||
+ | |||
+ | |||
+ | ======Array of Struct====== | ||
+ | If you have a function that defines locally a array of structs the compiler seems to code dump on compile. | ||
+ | <code c> | ||
+ | | ||
+ | int a; | ||
+ | int b; | ||
+ | }; | ||
+ | |||
+ | void func() { | ||
+ | | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | |||
+ | ======Function param same as function decl.====== | ||
+ | Although this is a coding mistake if you define a function header to use a variable name that is the same as function being invoke the compiler will not emit an error but will instead core dump. | ||
+ | <code c> | ||
+ | void world() { | ||
+ | } | ||
+ | void hello(int world) { | ||
+ | | ||
+ | | ||
+ | void main() { | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | ======Parse Error====== | ||
+ | Defining a variable in the middle of a code block is not allowed by the C compiler. | ||
+ | <code c> | ||
+ | void hello(int param) { | ||
+ | int i; | ||
+ | if (param == 0) return; | ||
+ | int j; //< | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | |||
+ | ======Unions====== | ||
+ | The 3.0.8 compiled is more than happy to compile the following although it will issue a warning about the unsigned as this is not supported until VM16. | ||
+ | <code c> | ||
+ | union value_T { | ||
+ | unsigned int ui; | ||
+ | int i; | ||
+ | }; | ||
+ | | ||
+ | </ | ||
+ | With all compilers after this version they will not support unions directly without error. | ||
+ | <code c> | ||
+ | | ||
+ | union { | ||
+ | unsigned int ui; | ||
+ | int i; | ||
+ | } u; | ||
+ | }; | ||
+ | | ||
+ | </ | ||
+ | |||
+ | |||
+ | ======Large Stack====== | ||
+ | The following legal code causes the assembler problems (at least on | ||
+ | my machine) using the Cybiko SDK. The assembler reports that "error - | ||
+ | argument 1 not in range -128..127" | ||
+ | <code c> | ||
+ | # | ||
+ | |||
+ | long main(int argc, char* argv[], bool start) | ||
+ | { | ||
+ | char info[80]; | ||
+ | | ||
+ | } | ||
+ | </ | ||
+ | I noticed that as well. It is due to the local stack growing too | ||
+ | large. To keep this from occuring, you can only have up to 128 | ||
+ | bytes of local variable storage. | ||
+ | |||
+ | The work around is to make larger local vars globals instead. | ||
+ | |||
+ | ======EOF Bug====== | ||
+ | FileInput_get_flags doesn' | ||
+ | |||
+ | **Bad Code** | ||
+ | <code c> | ||
+ | value = FileInput_get_flags(& | ||
+ | </ | ||
+ | |||
+ | **Good Code** | ||
+ | <code c> | ||
+ | value = Input_get_flags(& | ||
+ | </ | ||
+ | |||
+ | |||
+ | ======Math Bug====== | ||
+ | **Bad Code** | ||
+ | <code c> | ||
+ | char i; | ||
+ | i = -i; | ||
+ | </ | ||
+ | |||
+ | **Good Code** | ||
+ | <code c> | ||
+ | char i; | ||
+ | i = 0-i; | ||
+ | </ | ||
+ | |||
+ | |||
+ | ======Array Bug====== | ||
+ | When using arrays, trying to do math in the first parameter | ||
+ | will produce bad code but there is no compiler warning. | ||
+ | |||
+ | **Bad Code** | ||
+ | <code c> | ||
+ | int x,y,i; | ||
+ | i = Test[y/ | ||
+ | </ | ||
+ | |||
+ | **Good Code** | ||
+ | <code c> | ||
+ | int x, | ||
+ | ox = x/4; | ||
+ | oy = y/4; | ||
+ | i = Test[oy][ox]; | ||
+ | </ | ||
+ | OR | ||
+ | <code c> | ||
+ | int x,y,i,oy; | ||
+ | oy = y/4; | ||
+ | i = Test[oy][x/ | ||
+ | </ | ||
+ | ======draw_lib Bug====== | ||
+ | This is the function to use to draw " | ||
+ | |||
+ | If you wish to use the ' | ||
+ | (for horizontal &/or vertical flip of your graphic) then make sure | ||
+ | that these graphics are in their own file (in the filer.list file). | ||
+ | and that no other extremely large graphic is in the same file. | ||
+ | A large graphic in the same file will cause the FLIPs to not work. | ||
+ | The result will be nothing drawn. | ||
+ | |||
+ | ======Return from main Bug====== | ||
+ | Sometimes when exiting a program on the Cybiko, it will unexpectedly lock up. It doesn' | ||
+ | <code c> | ||
+ | return 0L; | ||
+ | </ | ||
+ | I've never had a lockup using this and all Cybiko SDK code does this making it seem like they knew about it but never got around to fixing it. |