64-bit ints and non-capable hardware
Dan Sugalski
INTVALs have to be 64 bit integers.
Does anyone know of a platform that has neither native nor emulated
64 bit integers? (One we're likely to run on, rather)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent Dax
# Okay, I'm about ready to just bite the bullet and declare that
# INTVALs have to be 64 bit integers.
#
# Does anyone know of a platform that has neither native nor emulated
# 64 bit integers? (One we're likely to run on, rather)
Mac Classic processors and Palm DragonBalls?
By the way, it looks like Palm OS now supports stdio emulation. I don't
know what versions it works for (it mentions using a Palm VII, which
uses 3.2, I think), but that should make porting much easier.
Apparently, you write a host app with a text box and scroll bar, then
tell the stdio emulation system what those are called. You then call a
specialized form of program; it must have linked in StdIOPalm.c. More
info:
<http://www.palmos.com/dev/support/docs/palmos/StandardIOApp.html#102439
4>.
***
The Palm OSR supports command line (UNIX style) applications for
debugging and special purposes such as communications utilities. This
capability is not intended for general users, but for developers. This
feature is not implemented in the Palm OS, but rather by additional C
modules that you must link with your application.
....
Summary of Standard IO
Standard IO Macros and Functions
fgetc
fgets
fprintf
fputc
fputs
getchar
gets
printf
putc
putchar
puts
SioAddCommand
Siofgetc
Siofgets
Siofprintf
Siofputc
Siofputs
Siogets
Sioprintf
Sioputs
Siosystem
Siovfprintf
sprintf
system
vfprintf
Vsprintf
Application-Defined Functions
SioMain
Standard IO Provider Functions
SioClearScreen
SioExecCommand
SioFree
SioHandleEvent
SioInit
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Bryan C. Warnock
> Okay, I'm about ready to just bite the bullet and declare that
> INTVALs have to be 64 bit integers.
Which INTVALs? INTVAL, IMHAOSBRPO[1], is overused internally.
I see little relative performance and size damage if INTVAL is made 64
bits and relegated only to user-space math as long as the internals
(pointer-tracking, sizes, offsets, etc) are left as native. You can
check and cast when numbers cross over. OTOH, converting all of the
internals to 64-bit is probably not such a good idea.
Of course, I registers are probably being used for both uses completely
independent of each other.
Or did I miss the point on wherefore 64-bit?
>
> Does anyone know of a platform that has neither native nor emulated
> 64 bit integers? (One we're likely to run on, rather)
If it has neither, the internals shouldn't be affected, although
user-space values will be. But you can convert to BigInt at 32 bits
vice 64. (Assuming that's still the plan.)
[1] In My Humble And Oft-Stated But Rarely Patching Opinion ;)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Martin D Kealey
> Okay, I'm about ready to just bite the bullet and declare that
> INTVALs have to be 64 bit integers.
>
> Does anyone know of a platform that has neither native nor emulated
> 64 bit integers? (One we're likely to run on, rather)
I'm fairly new to Parrot, but I've spent a while following standards tracks
for languages such as C and C++, and also using Perl, so hopefully I'm not
too far off the mark here...
I was wondering if anyone else followed the discussion in comp.std.c about
integer types, prior to the adoption of the C99 standard? There was a
substantial paper put out by Frank Farance, entitled "specification based
extended integer range" or SBEIR for short; see
http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/. It wasn't
adopted at the time, mostly because it was too big a lump to swallow, too
late in the standardisation process, but it looks like it might be timely
for Parrot to consider the concepts involved.
The basic idea is to express the requirements that a program has for its
integers, and let the compiler choose the best option;
minimum size
trap-on-overflow,
take-modulus-on-overflow,
exactness of size (for modulus operation),
compactness
speed
There were objections that this was too complex, and that some combinations
didn't make sense. To address the complexity, I proposed that integers
should be subcategorised as "classical" versus "logical".
"Classical" integers included all the existing C integer types, while
"logical" integers were those based on usage specification rather than
storage specification. In practice a logical specification would be
something like an exact range of values with trap-on-overflow, whereas a
classical or low level specification would be something like the range held
by a CPU register, with host-specific handling of overflows.
The relevance to Parrot is that, rather than opting for a short-list of
integer sizes like [8, 16, 32 and 64 bit], we should if possible allow an
extensible type system, possibly including optional automatic promotion to a
library-implemented integer type (BigNum, Complex, or whatever).
-Martin
(I find it quiet disappointing that "modern" languages like Java and C# rely
entirely on storage-based integer specifications "64 bit", when languages
like Pascal and Algol had range-specified integers 20 years ago.)
--
CAUTION: The information contained in this message is consequential and
subject to legacy provenance. If you are the intended recipient you are
hereby notified that reading this message is permitted. If you have not
received this message please notarise the sender and destroy the
originator.
Dan Sugalski
>Dan Sugalski:
># Okay, I'm about ready to just bite the bullet and declare that
># INTVALs have to be 64 bit integers.
>#
># Does anyone know of a platform that has neither native nor emulated
># 64 bit integers? (One we're likely to run on, rather)
>
>Mac Classic processors and Palm DragonBalls?
While the 68K doesn't do 64-bit natively, neither does the x86, but
gcc provides emulation, so that's not a problem. Dunno about the
DragonBall, but I'd bet we're out of luck generally for 64 bit stuff
there.
>By the way, it looks like Palm OS now supports stdio emulation.
Well, cool. That's darned good news.
Dan Sugalski
>On Mon, 2002-10-21 at 15:11, Dan Sugalski wrote:
>> Okay, I'm about ready to just bite the bullet and declare that
>> INTVALs have to be 64 bit integers.
>
>Which INTVALs?
I registers.
>INTVAL, IMHAOSBRPO[1], is overused internally.
>I see little relative performance and size damage if INTVAL is made 64
>bits and relegated only to user-space math as long as the internals
>(pointer-tracking, sizes, offsets, etc) are left as native. You can
>check and cast when numbers cross over. OTOH, converting all of the
>internals to 64-bit is probably not such a good idea.
>
>Of course, I registers are probably being used for both uses completely
>independent of each other.
Yeah, and they don't need to be. Most of the internals can leave
native integers to be whatever's most convenient and fastest
>Or did I miss the point on wherefore 64-bit?
Nope, that's pretty much it.
At this point, I think I've given up on requiring 64 bit ints. If
they're rare enough, then they can just be in PMCs and be done with
it. We can always revisit that decision later if it's really
important.
Rhys Weatherley
> I was wondering if anyone else followed the discussion in comp.std.c about
> integer types, prior to the adoption of the C99 standard? There was a
> substantial paper put out by Frank Farance, entitled "specification based
> extended integer range" or SBEIR for short; see
> http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/.
Very interesting proposal. I wish they had adopted it. Would
have saved me a lot of hassle with typedefs over the years. :-)
This kind of system works well in a statically compiled language
like C because the compiler can look at "signed int exact:32" and
say "Oh! That's just int on this platform!" and then compile
away the distinction.
I'm not sure how well it would work in a dynamic environment like
Parrot, where the compiler doesn't necessarily know the final actual
type. It is up to the runtime engine. e.g. how would the engine
rearrange the code to do "signed int exact:64" with PMC's on 32-bit
platforms and I registers on 64-bit? That way lies polymorphic
instruction sets and other CLI madness ...
Having said that, it might be nice to have a variant on BIGINT
that can be dynamically range-limited using dynamically-specified
rules. Then 64-bit ints can be created as instances of RANGEBIGINT.
Cheers,
Rhys.
P.S. I suspect one reason why it was rejected was because some
programmer would ask for "signed int exact:23517" and expect it
to work on every compiler. Implementing the intrinsics for
something like that is *hard*.
Martin D Kealey
> Martin D Kealey wrote:
> > [Frank Farance's paper] "specification based extended integer range"
> > [at] http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/.
> Very interesting proposal. I wish they had adopted it. Would
> have saved me a lot of hassle with typedefs over the years. :-)
Ditto!
> This ... works well in a statically compiled language like C because the
> compiler can ... say "Oh! That's just int on this platform!" and then
> compile away the distinction.
>
> I'm not sure how well it would work in a dynamic environment like
> Parrot, where the compiler doesn't necessarily know the final actual
> type.
I think the equivalent for Parrot would be
(1) a requirement to include a module "MEDIUMINT" (smaller than BIGINT), so
that large (but not arbitrarily large) numbers could be supported
(2) mechanisms to swap between that and INTVAL transparently at runtime, or
at least, to allow the compiler to generate both sets of code without
too much pain, or much impact on performance when the numbers are small
enough to be INTVAL.
(3) an opcode along the lines of "truncate to N bits", where N is fixed
(4) an opcode along the lines of "throw exception if wider than N bits",
where N is fixed
> It is up to the runtime engine. e.g. how would the engine rearrange the
> code to do "signed int exact:64" with PMC's on 32-bit platforms and I
> registers on 64-bit? That way lies polymorphic instruction sets and other
> CLI madness ...
(BTW: one of the criticisms of SBEIR was that "exact" and "signed" should
have been mutually exclusive.)
Rather than going the whole hog with polymorphic instruction sets, what
about supporting what I'll call "minor classes", which don't do inheritance
or runtime polymorphism, specifically to support MEDIUMINT and other modules
that mimic-but-extend native datatypes and operations, and are used as
stand-ins by the compiler?
> P.S. I suspect one reason why it was rejected was because some programmer
> would ask for "signed int exact:23517" and expect it to work on every
> compiler. Implementing the intrinsics for something like that is *hard*.
I think there was agreement that it would be OK for the compiler to limit
requests to 128 bits. For Parrot I would suggest that MEDIUMINT implement
at least 2048 bit (256 byte), which would be useful for implementing
cryptographic functions.
-Martin