Coming back here from another thread, AHelper pointed out that we have two kinds of storage available to programs, though the BFILE_* and MCS_* syscalls.

Our stdio implementation currently assumes BFILE_*, but it would be good to be able to handle either. I proposed adding another flag which fopen may accept (AHelper says 'i' would be reasonable), but there's also the option of URIs such as 'ram://foo.txt', although I really hate that concept.
There are probably other ways to handle it too, but I'm liking the idea of a flag to indicate which storage should be used (defaulting to flash).
Remember that one day, SD cards or other types of external memory may be supported, if not before, in newer Casio fx-CG models. So make sure the implementation allows for different types of storage.
Yes, ram:// sucks. I only put it in because, well, unix directories use /mnt/* or /media/* for other partitions and windows does C:\* D:\*, etc.. It isn't always platform independent. The 'i' flag is probably the best option as it will do what you expect. If you don't use the i flag, then it saves it to flash storage like you normally would.

My question is: What about the file size being required at the file creation? How does the current fopen handle it? What would be nice is to find out why that is required. From GlassOS: my best bet is that the OS doesn't watch file pointers. GlassOS requires an fopen and an fclose so that it can properly mark the size of the file. Is the prizm just making sure that you cannot corrupt it? If so, is there any way that we can manually create files by raw IO? Does the prizm even have a way to handle a corrupt fat (or whatever it uses)?
It has an "Optimize" function in the Memory menu, which, based in my experience, cleans leftovers in order to free the disk space you lost by working with files, and also speed things up a bit.

From the CG20 manual:
"Storage memory can become fragmented after many store and load operations, causing
entire blocks of memory to become unavailable for data storage. Because of this, you should
periodically perform the storage memory optimization procedure, which rearranges the data in
the storage memory and makes memory usage more economical.
• Note that the calculator performs storage memory optimization automatically whenever you
perform a save operation and the calculator discovers storage memory is running low."

I'm sure this doesn't handle a highly damaged filesystem, but it may help a bit and solve less serious problems (in order to avoid serious problems later).
That's fragmentation, not error checking. TIOS lets you garbage collection, but it doesn't handle a corrupt archive. Can anyone confirm that corruption is fixed? (I don't know how it will be corrupted in the first place :-X)
gbl08ma wrote:
Remember that one day, SD cards or other types of external memory may be supported, if not before, in newer Casio fx-CG models. So make sure the implementation allows for different types of storage.
Good point. It's not hard to add additional flags upon adding support for new backing stores, but it may also be a good idea to have some sort of 'fsetdefault' function to specify the default location for file operations to use.

AHelper wrote:
My question is: What about the file size being required at the file creation? How does the current fopen handle it?
It doesn't. I'll probably treat files like dynamic arrays with reasonably large initial values, recreating the file with a larger size when necessary. For now, you can't create new files.
What is the max filesize allowed? Don't forget that you have a 512KB stack space. (Your program uses some of that, since it is the stack, by the SDK doesn't give you the entire space.) I don't know how you would allocate that space, since it doesn't have a heap...

#define MAX_FILESIZE 400000
#include <stdio.h>

(inside stdio.h)
unsigned char FILE_BUF[MAX_FILESIZE];

?
AHelper wrote:
Don't forget that you have a 512KB stack space. (Your program uses some of that, since it is the stack, by the SDK doesn't give you the entire space.) I don't know how you would allocate that space, since it doesn't have a heap...

#define MAX_FILESIZE 400000
#include <stdio.h>

(inside stdio.h)
unsigned char FILE_BUF[MAX_FILESIZE];

?
More like _impl_file_buffer in stdio.c. In any case, file buffering should be handled on a per-file basis, not with a fixed global buffer like that.

If tests indicate that it will be useful (very likely), I'll implement support in crt0 for using a chunk of the stack as heap, and tweak malloc to support using both the system heap and the one on the stack. For now, it's not necessary, but I know there have already been projects that could have benefited from more heap space, so that's on my list of possible improvements.
Can you have it dynamic? For ex, I have a game that loads a lot of resources to the stack, so it would need to be dynamic. If you can make the stack formatted as a heap (optional), then that will solve problems. Otherwise, if the max filesize is small enough that you can fit it using a regular malloc (if there even is a max file size).

If there is no max file size and someone wants to save a 2mb file, then fopen and such will not work at making the file.
AHelper wrote:
Can you have it dynamic? For ex, I have a game that loads a lot of resources to the stack, so it would need to be dynamic. If you can make the stack formatted as a heap (optional), then that will solve problems. Otherwise, if the max filesize is small enough that you can fit it using a regular malloc (if there even is a max file size).
That's the logic behind putting stack reservation in crt0 (or I suppose crt1..) rather than libc itself, as that allows you to specify the amount of space to reserve (if any) at link time.

AHelper wrote:
If there is no max file size and someone wants to save a 2mb file, then fopen and such will not work at making the file.
It'll work, just inefficiently. I never said we'd store the whole file in memory, just that the file could be transparently resized as needed by recreating it (then closing the handle commits the file and drops any remaining unused space).
gbl08ma wrote:
OK, so as said on SAX, here are a list of things that need fixing:
* disp_tools.hpp is broken
* keyboard.hpp is lacking the definition for KEY_PRGM_0 (it should be 71)
* there are conflicting types for malloc and realloc in stdlib.h

And here's my build log for CGlock, with some errors caused by the new libfxcg and others caused by my code: http://pastebin.com/dBrcTPPF
I mucked about with headers so disp_tools.hpp should work now. You should really use <fxcg/display.h> at this point, though.

Haven't gotten to keyboard.hpp just yet, but that's an easy temporary fix for you. Same case as display, you should plan to use <fxcg/keyboard.h> once it's implemented.

I wasn't able to replicate the conflicting types error via tweaks to the example project, so I'll have to see your code to figure it out (assuming the latest build doesn't mysteriously fix it).

Your CFLAGS are all wrong though. These should be reasonable:

Code:
-Os -Wall -std=c99 -mb -m4a-nofpu -mhitachi
The one you really don't want is -nostdlib.
A bump here, I came up with a reasonable way of handling file resizing and writing.
Writing to storage memory (Bfile_*) is slow and limited in that files can't be resized, so using storage memory directly is a no-go. It could be mitigated by having dynamically-resized buffers for each open file, but managing buffers is a non-trivial amount of code and could easily exhaust the heap.

What I think is the way to proceed: put all open (and writable) files in main memory (MCS_*), which has many fewer restrictions since it's backed in RAM rather than flash. On closing a file, it will be moved to storage memory.

This solution addresses how to handle the distinction between storage and main memories (by not exposing main memory), the previous solution for which was reasonable, but required a lot of code and would have been a bit unusual in cases where one wanted to move a file between the two regions.

I haven't done anything with this yet mainly because I haven't grokked the MCS functions, but I'm currently planning hand off much of the MCS handling to Merth, as he says he already knows how to use it.
Do you plan to give programmers any control over that process, and if so, in what way and to what extent? On behalf of the Prizm programming community, my continued gratitude for the effort that you're putting into this!
KermMartian wrote:
Do you plan to give programmers any control over that process, and if so, in what way and to what extent?

No definite plan for such, but it's a possibility.

Opening a file for reading only shouldn't involve any movement of data (it'll just wrap the Bfile syscalls), but I could make it possible to inhibit writeback to storage memory on close, which could be useful in some situations. A flag to force opening a file in MCS may be similarly useful.
So, changes for the pycompat branch of libfxcg... Changes for stddef.h:
Code:
--- libfxcg/include/stddef.h    2012-07-31 14:10:28.185099838 -0500
+++ include/stddef.h    2012-07-31 14:19:16.692329788 -0500
@@ -7,12 +7,12 @@
 #define NULL 0
 #else
 #define NULL ((void*)0)
+// We don't do unicode of any sort.
+typedef unsigned char wchar_t;
 #endif
 
 #define offsetof(type, member) __builtin_offsetof(type, member)
 
-// We don't do unicode of any sort.
-typedef unsigned char wchar_t;
 
 #ifndef size_t
 typedef unsigned size_t;

In Bfile_SeekFile_OS, change line 3 to

Code:
SYSCALL(_Bfile_SeekFile_OS, 0x1DA9)

Make a new file Bfile_TellFile_OS and put in

Code:
#include <asm.h>

SYSCALL(_Bfile_TellFile_OS, 0x1DAB)

Here's the patch for the headers:

Code:
--- libfxcg/include/fxcg_syscalls.h     2012-07-31 14:10:28.184099862 -0500
+++ include/fxcg_syscalls.h     2012-07-31 14:45:41.740004665 -0500
@@ -1,3 +1,6 @@
+#ifdef __cplusplus
+extern "C" {
+#endif
 int ItoA_10digit( int, void* );
 void ByteToHex( unsigned char value, unsigned char*result );
 void HexToByte( unsigned char*value, unsigned char*result );
@@ -57,6 +60,7 @@
 int Bfile_OpenFile_OS( const unsigned short*filename, int mode );
 int Bfile_ReadFile_OS( int HANDLE, void *buf, int size, int readpos );
 int Bfile_SeekFile_OS( int handle, int pos );
+int Bfile_TellFile_OS( int handle );
 int Bfile_WriteFile_OS( int HANDLE, const void *buf, int size );
 void Bfile_NameToStr_ncpy( unsigned char*source, const unsigned short*dest, int n );
 void Bfile_StrToName_ncpy( unsigned short*dest, const unsigned char*source, int n );
@@ -174,3 +178,7 @@
 int Serial_Close( int mode );
 int Serial_DirectTransmitOneByte( unsigned char byte_to_transmit );
 int Serial_Open( unsigned char *mode );
+
+#ifdef __cplusplus
+}
+#endif


-------

For anyone not looking at github, I created a cmake build system that can make addins in a simpler way:

Code:
SET(CMAKE_TOOLCHAIN_FILE ../toolchain/Prizm.cmake)
project(example1)

file(GLOB EXAMPLE1_SRC "src/example1/*.c*")

add_executable(example1 ${EXAMPLE1_SRC})
makeg3a(example1 "example" "unselected.bmp" "selected.bmp")
That will compile all source files and produce a .g3a. I can post the Platform files once issues are resolved (when to projects are specified at once).
Just a note, the Jenkins builder for libfxcg was down for a bit because I moved to a new server and I didn't have the time/inclination to configure a cross-compiler on Debian. I ended up configuring another machine that already has the compiler installed (happens to be on Arch, where my AUR packages work fine) as a builder for libfxcg (Jenkins' support for remote builders makes me happy, since it was very easy to configure).

If you weren't aware of this: http://jenkins.taricorp.net/
Configured to automatically build libfxcg when changes are pushed to git, so you can stay on the cutting edge with relative ease.
Can someone release a new sdk package with libfxcg installed? Thanks in advance.
Since this topic is sticky and filled with libc, posting this here:

µClibc, µClibc++, and glibc all use LGPL, GCC uses GPL. libgcc has a GCC Runtime Exception, so not a lot of worries there Smile

For LGPL, as I have found, you may statically link and distribute the final linked binary so long that the recipient is able to do linking on their own. This requires the .o object files to be distributed with the add-in (or any other object code that is not linked to the lgpl libraries)

uClibc wrote:
If you distribute an application which has uClibc statically linked, you must also make your application available as an object file which can later be re-linked against updated versions of uClibc.


osdev wrote:
Object files linked to LGPL'ed code are unaffected by the LGPL, but users must be able to link themselves (i.e., distribute your non-(L)GPL'ed object files separately, not linked to the LGPL'ed code).


LGPL 4d0 wrote:
Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
Can we just distribute the C source code for uclibc along with the software that uses it, instead of the object files? Since I don't like having those on git repos.
You could, but it would be a lot of extra code. Might make the most sense to use a git submodule or such.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement