Okay, I have reverted most of my changes and just left the minimal amount required to keep Gambit working on the DS. The repl is still broken, but it's very strange.
I'm wondering if this is some form of endianness/type size failure due to the cross compile:
Gambit Version 4.0 beta 20
0
3
1
2
2
1
3
0
4
7
5
6
6
5
7
4
8
*** ERROR IN (console)@9.1 -- Unbound variable: 8 1>
Any ideas?
Thanks, -a
Afficher les réponses par date
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24-Oct-06, at 5:52 AM, Andrew Lentvorski wrote:
Andrew Lentvorski wrote:
I'm wondering if this is some form of endianness/type size failure due to the cross compile:
It was indeed an endianness failure.
Can you explain how you fixed the problem? The file include/gambit.h contains ifdefs to automatically figure out what the endianness is. In particular it contains:
#ifndef CPU_arm
#ifdef arm #define ___CPU_arm #else #ifdef __arm #define ___CPU_arm #else #ifdef __arm__ #define ___CPU_arm #endif #endif #endif
#endif
#ifdef ___CPU_arm #ifdef _LITTLE_ENDIAN #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN__ #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN_DATA__ #define ___LITTLE_ENDIAN #endif #endif
The endianness (and word size) of the build and execution environments are completely unrelated. The C code produced by the compiler can be compiled for an execution environment that is either big endian or little endian, and with 32 or 64 bit words. However, if the processor is not recognized by gambit.h, it will assume the processor is big endian with 32 bit addressing.
Marc
Marc Feeley wrote:
Can you explain how you fixed the problem? The file include/gambit.h contains ifdefs to automatically figure out what the endianness is. In particular it contains:
I simply did:
#ifdef ___CPU_arm
#define _LITTLE_ENDIAN
#ifdef _LITTLE_ENDIAN #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN__ #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN_DATA__ #define ___LITTLE_ENDIAN #endif #endif
For some reason, nothing sets a _LITTLE_ENDIAN flag in the DS development environment. <shrug>
It also probably doesn't help that I'm cross compiling from OS X PPC which is big endian. So, all of the configure and makefiles run under that to produce the C code. My scons files then handle the cross compiling to the DS.
As of now, I have a 3 Mibibyte binary which produces a repl with a console and emulated keyboard on the screen and touchscreen. It works on both hardware and under the no$gba emulator. It's still a little strange in that it evaluates before I hit return if there is a parenthesis, eg.:
Gambit Version 4.0 beta 20
(+ 1 2 3)6 (cons 'a '(1 2))(a 1 2) 1
1
'a
a
So, my next step is to try to bring networking up. Is the fact that I have no native threading system going to impact that?
Thanks, -a
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24-Oct-06, at 8:39 AM, Andrew Lentvorski wrote:
Marc Feeley wrote:
Can you explain how you fixed the problem? The file include/ gambit.h contains ifdefs to automatically figure out what the endianness is. In particular it contains:
I simply did:
#ifdef ___CPU_arm
#define _LITTLE_ENDIAN
#ifdef _LITTLE_ENDIAN #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN__ #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN_DATA__ #define ___LITTLE_ENDIAN #endif #endif
For some reason, nothing sets a _LITTLE_ENDIAN flag in the DS development environment. <shrug>
It also probably doesn't help that I'm cross compiling from OS X PPC which is big endian. So, all of the configure and makefiles run under that to produce the C code. My scons files then handle the cross compiling to the DS.
As of now, I have a 3 Mibibyte binary which produces a repl with a console and emulated keyboard on the screen and touchscreen. It works on both hardware and under the no$gba emulator.
That's great! It makes me want to buy a Nintendo DS just to try it out! 3MB seems a bit big though. Did you try any of my suggestions to cut down on code size?
It's still a little strange in that it evaluates before I hit return if there is a parenthesis, eg.:
Gambit Version 4.0 beta 20
(+ 1 2 3)6 (cons 'a '(1 2))(a 1 2) 1
1
'a
a
This is normal because your "stdin" is directly reading from the keyboard, and the "read" procedure will know the expression is complete when it reads the closing parenthesis or the whitespace after a symbol, number, etc.
Gambit's line editing feature is implemented in lib/os_tty.c and it is enabled by a "#define USE_LINEEDITOR" in lib/os.h (which is the default). But for this to work on a non-POSIX/non-WIN32 system you have to complete the implementation of the functions ___device_tty_read_raw_no_lineeditor and ___device_tty_write in lib/ os_tty.c so that they read/write to the "console" with no buffering. You also have to change ___os_device_stream_open_predefined in lib/ os_io.c so that when index==-4 it opens the console with a call to ___device_tty_setup_console (like for POSIX and WIN32).
Where does the output of the "console" go? Does it go to the screen? Does it support cursor movement and xterm/vt100 escape codes? If not you have to complete the implementation of the function lineeditor_output_terminal_op in lib/os_tty.c .
So, my next step is to try to bring networking up. Is the fact that I have no native threading system going to impact that?
Of course once you have networking, you can just use remote debugging with emacs and it will take care of the line-editing.
I assume you know about DS Wifi (http://akkit.org/dswifi/) and lwIP (http://masscat.afraid.org/ninds/lwip.php).
For the threading system to work, you will need a heartbeat interrupt (complete the implementation of setup_heartbeat_interrupt_handling and friends in lib/os_time.c) and non-blocking I/O, at least for networking (I think lwIP support non-blocking sockets). You will have to "#define USE_NETWORKING" in lib/os.h and complete the implementation of the sections "TCP client stream device" and "TCP server device" in lib/os_io.c .
This is not an easy task but I can help you figure out what needs to be done. In the interest of keeping the mailing-list traffic down I will stop cross-posting to the mailing-list.
Marc
On Oct 24, 2006, at 11:02 AM, Marc Feeley wrote:
In the interest of keeping the mailing-list traffic down I will stop cross-posting to the mailing-list.
Well, I find this discussion very interesting. I don't mind the mail list traffic (among my 30-40 spam e-mails a day that get through my filter).
Brad
I agree, this is a very interesting discussion.
2006/10/24, Bradley Lucier lucier@math.purdue.edu:
On Oct 24, 2006, at 11:02 AM, Marc Feeley wrote:
In the interest of keeping the mailing-list traffic down I will stop cross-posting to the mailing-list.
Well, I find this discussion very interesting. I don't mind the mail list traffic (among my 30-40 spam e-mails a day that get through my filter).
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc Feeley wrote:
That's great! It makes me want to buy a Nintendo DS just to try it out! 3MB seems a bit big though. Did you try any of my suggestions to cut down on code size?
Well, the system does a strip automatically when preparing the nds image. I haven't tried any of the other things because I wanted as much as possible available when I tried networking.
At some point, I'll have to post a binary somewhere for people to try. Especially since it works under the emulators.
This is normal because your "stdin" is directly reading from the keyboard, and the "read" procedure will know the expression is complete when it reads the closing parenthesis or the whitespace after a symbol, number, etc.
Ah. Fine then. I'll leave it alone.
Where does the output of the "console" go? Does it go to the screen? Does it support cursor movement and xterm/vt100 escape codes? If not you have to complete the implementation of the function lineeditor_output_terminal_op in lib/os_tty.c .
It goes to the screen. The screen does support ANSI escape codes. However, I'll probably ignore that for now.
I assume you know about DS Wifi (http://akkit.org/dswifi/) and lwIP (http://masscat.afraid.org/ninds/lwip.php).
Yes, the lwIP implementation isn't completed and DS Wifi has its own somewhat quirky TCP system. I really wish he had used lwIP instead.
For the threading system to work, you will need a heartbeat interrupt (complete the implementation of setup_heartbeat_interrupt_handling and friends in lib/os_time.c)
Heartbeat interrupt. On the DS that's *really* easy. I'll set one of the timers to fire at once every couple of seconds initially. With all the debug logging going to flash it's slowing the system down pretty dramatically.
and non-blocking I/O, at least for networking
Okay, that can be done, but it needs to use the ioctl calls instead of the the fcntl calls.
(I think lwIP support non-blocking sockets). You will have to "#define USE_NETWORKING" in lib/os.h and complete the implementation of the sections "TCP client stream device" and "TCP server device" in lib/os_io.c .
Got it.
This is not an easy task but I can help you figure out what needs to be done. In the interest of keeping the mailing-list traffic down I will stop cross-posting to the mailing-list.
Unless you really don't want me to, I'd like to keep crossposting. Having this discussion in a publicly available archive for the next person who wants to port Gambit to something else would be very useful.
-a
On Oct 24, 2006, at 6:13 PM, Andrew Lentvorski wrote:
Marc Feeley wrote:
That's great! It makes me want to buy a Nintendo DS just to try it out! 3MB seems a bit big though. Did you try any of my suggestions to cut down on code size?
Well, the system does a strip automatically when preparing the nds image. I haven't tried any of the other things because I wanted as much as possible available when I tried networking.
Defining ___OPTIMIZE_SPACE in gambit.h and changing
(##define-macro (use-fast-bignum-algorithms) #t)
to
(##define-macro (use-fast-bignum-algorithms) #f)
in _num.scm (a recompile of _num.scm would then be necessary) shouldn't remove any functionality and may cut the size significantly.
Brad