Jay A. Kreibich wrote:
> On Wed, May 07, 2008 at 10:25:49PM -0400, Andrew Cunningham scratched on the 
> wall:
>
>   
>> "I have doubts that you will be able to get SQLite to work on anything
>> less than a 32-bit processor.
>> D. Richard Hipp"
>>     
>
>   
>> I was under the impression as long as the processor had enough room to
>> hold the program (and RAM) it would work.
>>     
>
>   Yeah, but you have to compile it first...
>
>   
>> The difference I would have
>> expected would simply be speed of execution, but eventually getting
>> there.  With simple inserts/queries and the speed of sqlite, I thought
>> it should be okay.
>>     
>
>   I suspect the issue has to do with 64-bit integer support.  SQLite does
>   a lot with native 64-bit integer values (e.g. "unsigned long long int").
>   Most 32-bit processors have instructions that can deal with 64 bit
>   values as single, whole values, even if they require a lot of
>   slight-of-hand behind the scenes.  Even if the processor doesn't have
>   explicit instructions, the compiler can often fake it by using the 
>   overflow bits and a lot of byte shuffling.
>
>   I suppose it would be possible to play the same games with a 16 bit
>   (or even 8) processor, but I'm guessing the compilers for most of
>   these smaller chips don't support long long ints.  Even if they do,
>   it is going to be pretty slow and inflate the code side.
>
>     -j
>
>   

    I once thought about trying to compile it with "cc65" to run on an 
Apple IIe, for fun.  I then calculated that the Apple II doesn't have 
enough RAM in a flat address space.  I then decided that I'd rather go 
outside and enjoy the sunshine. :)

    However... I still wonder if it would be possible.  Maybe if the 
compile could automatically split the code into sections that could work 
like "overlays" did back in the Borland C/Pascal days on MS-DOS.  But I 
suspect that memory access would be a problem....

    I could also compile Sqlite into MIPS R2000, and write a small 
emulator to run on the Apple (that transparently handled bank-switching 
and paging RAM).  That might work.  Slowly...


-- 
CONFIDENTIALITY NOTICE
This electronic mail and the information contained herein are intended for the 
named recipient only.  It may contain confidential, proprietary and/or 
privileged information.  If you have received this electronic mail in error, 
please do not read any text other than the text of this notice and do not open 
any attachments. Also, please immediately notify the sender by replying to this 
electronic mail or by collect call to (262) 796-0925. After notifying the 
sender as described above, please delete this electronic mail message 
immediately and purge the item from the deleted items folder (or the 
equivalent) of your electronic mail system. Thank you.

--

The above email disclaimer is required by our legal department.  However, if 
you would like a more humorous disclaimer, check here: 
http://www-users.cs.york.ac.uk/susan/joke/disclaim.htm


_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to