|Re: 35s - how fast?|
Message #7 Posted by hugh steers on 17 July 2007, 6:44 p.m.,
in response to message #4 by Eric Smith
the choice of the 6502 architecture i find perplexing. i understand that hp might not have had the luxuary to change from the 33s, but that doesn't explain the 33s. the compiler point is important and i think that there are better choices than the 6502.
presumably there is not an ARM slow, cheap or low power enough to fit the bill. good compilers were built for the old 8086 architecture which might make an alternative. dust down your old copies of turbo C, and return (const char FAR*)FuManchu; well perhaps not.
but seriously, unless they're doing something really funky, i would expect the biggest limitation is a 64k address space. with 32k RAM, then you've only got 32K rom. this rules out adding a lot of extra function. which is why stuff might be missing already.
so better than segments might be our old friend the 68000, eg 16MHz dragonball like the palm had. flat architecture with mature compilers.
one thought; is there an architure licensing cost. for example is the 6502 now effectively free? when all others would require, at least some, license.
also, i had an idea about your ADD code.
Gene's article mentiones 15 decimal internal precision and an 8 byte mantissa (without signs). if i had to write the code in C for the 6502 or someting like that, i'd implement a base 100 decimal system with 2 digits per byte stored in binary. since without leveraging the decimal instructions of the 6502, arithmetic will be a shift and mask extravaganza or else write the math code by hand.
so with a base 100, you need a spare "padding" nybble that means 8 bytes gives you only 15 digits. which is what you've got, so maybe this is what they actually do.
im using the same idea in hplua but with base 10,000 each "digit" of 0 to 9999 stored in 16 bits. the idea is that i get to use 16x16->32 multiply and replace divide constants with inverted mul constants BUT the hit is that i waste 3 nybbles in this base. this isn't so bad because my floats are 16 bytes (compared to 35s 12 bytes). i also take a hit converting each 16 bit binary to and from decimal for IO, but this is not signigicant overall.