Re: standard representations
On Fri, Jan 05, 2001 at 11:20:06AM -0600, Garrett Goebel wrote: Visual Basic has been growing up too. And it's a whole lot easier to work with the Win32 API, COM, ADSI, COM, etc. than Perl. This is now firmly off-topic, but... DevKit? -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Re: standard representations
At 09:11 AM 1/5/01 -0600, Jarkko Hietaniemi wrote: On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote: On Fri, 5 Jan 2001, Bradley M. Kuhn wrote: I personally think that the relying on LGPL'ed code is completely reasonable. Some will disagree, so we need to come to a consensus on this as a community. There are actually a couple of different mostly-independent issues, but yes, we'll need to face them seriously fairly early on, I think. (Not just yet, perhaps, but probably soon.) 1. What are the consequences for those who redistribute software based on or including perl6? This is a licensing issue that I do not feel If we botch this, this is the point that may stop commercial vendors from including Perl in their core distribution, or even building upon Perl (as Alan^WSun has already made with Solaris 8 and kstat(1)). This is definitely a biggie. I really want perl shippable with any piece of software. Screw Visual Basic, Perl should be the scripting language of choice for, well, everything! :) competent to address, and hence won't. 2. How do we handle build/install issues? a. Do we insist that users install the package first? If so, what do we do about portability problems? For example, gmp (the GNU multiprecision arithmetic library that's at issue here) hasn't been ported to VMS (at least last time I checked) while VMS is a supported platform for perl. This is also a biggie. I do not think insisting would be a winning solution. Even if the software has been ported to platform mumbletyspratz, any additional piece of software one has to install raises the bar of installing Perl. And, if there's no port of a library blah to mumbletyspratz, the bar will be even higher. "Let's then just port blah to mumbletyspratz" just isn't a realistic suggestion. There are far too many blah-mumbletysptraz combinations out there. Everything needs to be optional. Yes. The things perl needs should be shipped with, and build with, perl. Everything else should be optional, or as a third-party module installable via CPAN. We can ship slower or less-functional alternatives (fgmp instead of gmp for math, for example, the way we do with SDBM) that can be replaced, but we must have perl as a complete kit, requiring just a compiler and build tool to build. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: standard representations
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Screw Visual Basic, Perl should be the scripting language of choice for, well, everything! :) Well... then someone needs to make it easier to dynamically access the Win32 API from Perl. Visual Basic has been growing up too. And it's a whole lot easier to work with the Win32 API, COM, ADSI, COM, etc. than Perl. No reading 1600+ pages of obfuscated mind bending XS documentation, C Macro's, and Perl Internals. No compiling DLL's every time you need to access functions in shared libraries. You really have to be an C coder to do Perl=C. Perl's not going to move in on VB-land any time soon... o Aldo Calpini's Win32::API module is nice, but does nothing for helping Joe Perl user with C data structures and callbacks. o Brian Ingerson's Inline module is also nice, makes serious inroads on callbacks and type mapping, but adds the requirement of a C compiler. o Paul Moore's FFI is a cross-platform Win32::API. Rough but nice... and not likely to have those rough edges smoothed out any time in the near future o John Tobey's C::DynaLib is mostly dead o XS is bad enough for Joe Perl user that at least 4 serious attempts have been made to make Perl=C feel more like Perl, and less like C, C Macro, and Perl Internals XS sadomasochism. Garrett
public domain? (was Re: standard representations)
At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I'm beginning to loathe software licenses in a *big* way, and I'm a half step away from saying to hell with it all and going fully public domain. (Or at least pushing for it, as I don't control perl's licensing terms) Public domain has it's own troubles too. To be safe in doing a public domain license, we'll need to get copyright disclaimers from everyone who contributes code (and possibly their employers). Otherwise, someone could come along later and legally claim copyright on some part. Dan Sugalski [EMAIL PROTECTED] wrote: No worse than what we need now. Submitting code to perl places it under the license that perl uses, if it's to be included. I am not completely sure this is correct, but only a copyright lawyer could tell us for sure. My worry is that when you submit a patch to Perl, you've already seen and been made aware of its license it's a bit more clear that one agrees to release their software under that license. You still claim copyright, but you are at least implicitly licensing it under perl's license. Public domain is a disclaimer of copyright. It seems to me that it's much harder to infer that, by submitting a patch, someone meant to say: "I give up all copyright on this work" than it is to infer: "I am submitting this copyrighted work of mine to a project whose license I know, and therefore it's under the same license." But, this is a question for a copyright lawyer. OTOH, digital signatures are apparently now legally valid in the USA (although the details still aren't clear to me). We could just ask everyone to PGP or GPG sign a message that says: "I disclaim copyright", which isn't a hard task. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: standard representations
Andy Dougherty [EMAIL PROTECTED] wrote: (Does the LPGL and the existence of fgmp make it ok to distribute the interface/XS code and rely on the end user to install gmp if they so choose? Ick. I hate licensing problems.) This is actually one of the reasons I'd like to see the licensing working group to continue indefinitely. We need to decide: "Do we want perl6 to depend on libraries with somewhat stricter licenses?" I personally think that the relying on LGPL'ed code is completely reasonable. Some will disagree, so we need to come to a consensus on this as a community. Also, note that as long as our license is compatible with the LGPL (and most licenses are). There are no licensing problems for us, but we might be creating hassles for those who redistribute proprietary software versions of perl. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] wrote: I'm beginning to loathe software licenses in a *big* way, and I'm a half step away from saying to hell with it all and going fully public domain. (Or at least pushing for it, as I don't control perl's licensing terms) Public domain has it's own troubles too. To be safe in doing a public domain license, we'll need to get copyright disclaimers from everyone who contributes code (and possibly their employers). Otherwise, someone could come along later and legally claim copyright on some part. Liceses. Bletch. Don't blame the licenses, blame the copyright law that makes them an unfortunate necessity in many cases. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: standard representations
Nick Ing-Simmons [EMAIL PROTECTED] wrote BigFloat could well build on BigInt for its "mantissa" and have another int-of-some-kind as its exponent. We don't need to pack it tightly so we should probably avoid IEEE-like hidden MSB. The size of exponent is one area where "known range of int" is important. Or we could go the really obscene route and implement bigfloat using bigints for both mantissa *and* exponent. Not much danger of overflow then ;-)
Re: standard representations
At 11:58 PM 1/1/01 +, Tom Hughes wrote: In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote: ARM7/ARM9 are both 32-bit MIPS has both 32-bit and 64-bit variants. That's good. Though do either of them have 16-bit data busses? If you ignore thumb mode all ARM chips are 32 bit as far as the data bus and registers go, at least at the CPU core interface. You could of course hook up a 16 bit bus to the core and force the high bits to always be zero or similar. Offhand I can't remember if thumb mode uses 16 bit data as well as 16 bit instructions. I was thinking of chips like the 68008, which had a 16-bit data bus. While the native word size was 32 bits, fetching one took two trips out to memory. Done automagically for you by the chip's circuitry so you didn't have to worry, but 16-bit integers were markedly faster to use than 32-bit ones. Nobody may do that any more, but I think extra pins off a chip still cost something, so they may still do it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 10:14 AM 1/2/01 +, David Mitchell wrote: Nick Ing-Simmons [EMAIL PROTECTED] wrote BigFloat could well build on BigInt for its "mantissa" and have another int-of-some-kind as its exponent. We don't need to pack it tightly so we should probably avoid IEEE-like hidden MSB. The size of exponent is one area where "known range of int" is important. Or we could go the really obscene route and implement bigfloat using bigints for both mantissa *and* exponent. Not much danger of overflow then ;-) The sick thing was, I was actually considering this... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote: but you seem to agree that porting to most embedded type systems is more of an OS (and testing!) issue than compilation. if other complex enough I think there are true limits imposed by the more limited CPUs like address space. I think there might be nasty assumptions one easily makes that work only on 32-bit or more address spaces. Any assumptions spring to mind, besides "we can eat lots of memory"? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
On Tue, Jan 02, 2001 at 07:26:39AM -0500, Dan Sugalski wrote: At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote: but you seem to agree that porting to most embedded type systems is more of an OS (and testing!) issue than compilation. if other complex enough I think there are true limits imposed by the more limited CPUs like address space. I think there might be nasty assumptions one easily makes that work only on 32-bit or more address spaces. Any assumptions spring to mind, besides "we can eat lots of memory"? None right now but then again it's my early morning precoffee brain... Are there any places with 32b ints and 16b ptrs? If so, casting ints to pointers and back would be even more debatable than usual. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: standard representations
On Tue, 2 Jan 2001, Dan Sugalski wrote: that got wedged into an 8K address space with overlays...) but I'm pretty sure I could do it on a PDP-11, with it's 64Kwords of ID space. Probably not the baseline, all-C version of the source, but perl nonetheless. Oh, then perhaps we should put the PDP-11 memory model probes back into Configure? :-) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
At 09:42 AM 1/2/01 -0500, Andy Dougherty wrote: On Tue, 2 Jan 2001, Dan Sugalski wrote: that got wedged into an 8K address space with overlays...) but I'm pretty sure I could do it on a PDP-11, with it's 64Kwords of ID space. Probably not the baseline, all-C version of the source, but perl nonetheless. Oh, then perhaps we should put the PDP-11 memory model probes back into Configure? :-) Nah--if I was going to do a RSTS/E port of perl, I'd rewrite most of the guts in assembly anyway, so there wouldn't be a whole lot of point... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 07:33 AM 1/2/01 -0600, Jarkko Hietaniemi wrote: On Tue, Jan 02, 2001 at 07:26:39AM -0500, Dan Sugalski wrote: At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote: but you seem to agree that porting to most embedded type systems is more of an OS (and testing!) issue than compilation. if other complex enough I think there are true limits imposed by the more limited CPUs like address space. I think there might be nasty assumptions one easily makes that work only on 32-bit or more address spaces. Any assumptions spring to mind, besides "we can eat lots of memory"? None right now but then again it's my early morning precoffee brain... Are there any places with 32b ints and 16b ptrs? If so, casting ints to pointers and back would be even more debatable than usual. I'm going to try really hard to avoid that particular pitfall, if for no other reason than you can set things on the VMS C compilers such that you have 64-bit pointers and 32-bit ints by default. (Takes some work, but it's doable) I think some of the platforms do Odd Things for pointers to functions as well that might cause this assumption to fail. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
On Sat, 30 Dec 2000, Andy Dougherty wrote: Anyone know of a good bigint/bigfloat library whose terms are such that we can just snag the source and use it in perl? There's a clone of the GPL one that was written specifically to avoid GPL issues. I'll try to dig up more references when I'm in next week. Ah, yes. The original GPL one was called gmp. Since it was released under the GPL and it was the only library with that particular API, there were some interesting copyright implications. See http://www.ptf.com/ptf/products/UNIX/current/0264.0.html for some editorializing. Primarily in response to this, fgmp was written as a public domain library. The most recent version I found in a less-than-exhaustive search was http://munitions.vipul.net/software/libraries/mathematics/fgmp-1.0.1.shar Now that gmp is licensed under the LPGL (see http://www.swox.com/gmp/ ) it isn't obvious to me how much to worry about all this. One other possibility that turned up was 'calc'. http://www.isthe.com/chongo/tech/comp/calc/index.html At first glance, it appears to have much more lenient licensing, but isn't really packaged as an easy-to-build-and-use library. (Again, this was a brief stint with a search engine, not an exhaustive search.) My main conclusion: If you want to experiment with modifying perl5's bigints and bigfloats with a tuned library to get an idea of how much speed we're talking about, gmp is probably the best bet to get a good estimate with the least amount of effort (though it doesn't look as if it's been ported to VMS, and it didn't build for me under Solaris 8 when I just tested it ...). If you want to redistribute the code, of course, then you need to think about licensing issues. (Does the LPGL and the existence of fgmp make it ok to distribute the interface/XS code and rely on the end user to install gmp if they so choose? Ick. I hate licensing problems.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS sure I could do it on a PDP-11, with it's 64Kwords of ID DS space. Probably not the baseline, all-C version of the source, but DS perl nonetheless. that would warm the nostalgic cockles of my heart. :) which OS? rt-11 was my favorite! uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: JH None right now but then again it's my early morning precoffee JH brain... Are there any places with 32b ints and 16b ptrs? If so, JH casting ints to pointers and back would be even more debatable JH than usual. having been majorly bitten in the derriere by a port project of a 32 bit DBMS to alpha and their HEAVY asumption of 32 bit ints and pointers being the same size, i would make sure we NEVER assume that pointers and ints are similar in size. use unions if we have to but no casting please. shuddering from the nightmare flashbacks uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
At 12:41 PM 1/2/01 -0500, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I was thinking of chips like the 68008, which had a 16-bit data DS bus. While the native word size was 32 bits, fetching one took two DS trips out to memory. Done automagically for you by the chip's DS circuitry so you didn't have to worry, but 16-bit integers were DS markedly faster to use than 32-bit ones. DS Nobody may do that any more, but I think extra pins off a chip DS still cost something, so they may still do it. but that is all transparent to the software as you point out. thinking about memory cycles here is premature optimization. No, I don't think so. In this case, the natural word size really is 16 bits, regardless of what's transparent to the programmer. (Just as 32-bit integers seem fastest for many things on Alphas, despite the fact that it's a 64-bit processor) All I want to do is make sure there are real-world cases of smallish integer machines that perl may want to run on, and I think that's been established now. so let's stop worrying about embedded stuff now. if we make the primary integer size a config option with proper defaults, that should allow any embedded ports to do their thing. worrying about saving a bus cycle in a perl program is kinda silly. I think you'll find that's not the case, really. While it's a little early to grovel over bits of the code, now is *exactly* the time to make sure the core architecture's got no overt gotchas in it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 12:43 PM 1/2/01 -0500, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS sure I could do it on a PDP-11, with it's 64Kwords of ID DS space. Probably not the baseline, all-C version of the source, but DS perl nonetheless. that would warm the nostalgic cockles of my heart. :) which OS? rt-11 was my favorite! RSTS/E, of course. If for no other reason than I've never used RT-11 or RSX. (Well, unless you count VMS in as an RSX variant...) A rather nice OS, all things considered. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 12:43 PM 1/2/01 -0500, Uri Guttman wrote: which OS? rt-11 was my favorite! DS RSTS/E, of course. If for no other reason than I've never used DS RT-11 or RSX. (Well, unless you count VMS in as an RSX variant...) DS A rather nice OS, all things considered. infidel! rt-11 was the true ancestor of cp/m and the evil winblows. it should have a perl port for historical reasons alone. and it had disk and ram OVERLAYS support up the wazoo. 22 bits pf physical ram could be mapped into the 64k address space. kinda like reverse virtual memory. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
At 12:58 PM 1/2/01 -0500, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 12:43 PM 1/2/01 -0500, Uri Guttman wrote: which OS? rt-11 was my favorite! DS RSTS/E, of course. If for no other reason than I've never used DS RT-11 or RSX. (Well, unless you count VMS in as an RSX variant...) DS A rather nice OS, all things considered. infidel! rt-11 was the true ancestor of cp/m and the evil winblows. And this would be a *good* thing how, exactly? :) it should have a perl port for historical reasons alone. and it had disk and ram OVERLAYS support up the wazoo. 22 bits pf physical ram could be mapped into the 64k address space. kinda like reverse virtual memory. As did RSTS. With compiled basic programs, no less. :-P (Nothing quite like wedging a 500K executable into 64k of I-space. Now *that* was always fun...) This, alas, is wildly off-topic, so we should probably stop. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS No, I don't think so. In this case, the natural word size really DS is 16 bits, regardless of what's transparent to the DS programmer. (Just as 32-bit integers seem fastest for many things DS on Alphas, despite the fact that it's a 64-bit processor) All I DS want to do is make sure there are real-world cases of smallish DS integer machines that perl may want to run on, and I think that's DS been established now. i would disagree. the natural size is usually the register size. the buz size is usually just a cost and packaging consideration. the 8088 and 8086 ran the same software. the former had an 8 bit buss for cheaper systems. same with the low end 68k chips. general purpose software always was written independently of the bus size. only RTOS like programs cared enough about bus cycles to require coding 16 bit ints. DS I think you'll find that's not the case, really. While it's a DS little early to grovel over bits of the code, now is *exactly* the DS time to make sure the core architecture's got no overt gotchas in DS it. that is different. i said we should have the option to set the default int size at config time. but we can't change the pointer size (in most cases) so even on the 32/16 68k chips you would be penalized by every pointer access. making the int 16 bits by default makes no sense then. let the OS port worry about that and let them have the option to select it. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
On Tue, 2 Jan 2001, Dan Sugalski wrote: At 12:34 PM 1/2/01 -0500, Andy Dougherty wrote: If you want to experiment with modifying perl5's bigints and bigfloats with a tuned library to get an idea of how much speed we're talking about, gmp is probably the best bet to get a good estimate with the least amount of effort (though it doesn't look as if it's been ported to VMS, and it didn't build for me under Solaris 8 when I just tested it ...). If you want to redistribute the code, of course, then you need to think about licensing issues. I think gmp/fgmp is probably the best place to start, if I can get the fgmp code building with enough abuse. It ought to be simple enough, and we'll need to smack it around some for perl's memory management anyway. Math::GMP is on CPAN already. It does operator overloading. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: standard representations
In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote: ARM7/ARM9 are both 32-bit MIPS has both 32-bit and 64-bit variants. That's good. Though do either of them have 16-bit data busses? If you ignore thumb mode all ARM chips are 32 bit as far as the data bus and registers go, at least at the CPU core interface. You could of course hook up a 16 bit bus to the core and force the high bits to always be zero or similar. Offhand I can't remember if thumb mode uses 16 bit data as well as 16 bit instructions. References to older ARM chips not being 32 bit refer only to the address space which was 26 bit on ARM 2 and ARM 3 cores. Later cores added a 32 bit mode and the latest cores drop the 26 bit support. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I was reading the dictionary. I thought it was a poem about everything.
Re: standard representations
At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: I'm reasonably certain that all platforms that perl will ultimately run on can muster hardware support for 16-bit integers. Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - they have a tendency to widen to 32-bits. That's fine. I was thinking of smaller processors that might be used in embedded apps and such. (I'm also not sure what's the most efficient integer representation on things like the ARM microprocessors are) ARM7/ARM9 are both 32-bit MIPS has both 32-bit and 64-bit variants. That's good. Though do either of them have 16-bit data busses? DSPs are more messy. That's probably a bit too specialized a piece of hardware to worry about. Unlss things have changed lately, they're not really general-purpose CPUs. It is micro-controllers that you have to worry about Yeak, I know a lot of the old 8 and 16 bit chips are in use as control devices places. Those are the ones I'm thinking about. (Not that hard, but I don't want to rule them out needlessly) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 08:05 PM 12/30/00 -0500, Andy Dougherty wrote: On Sat, 30 Dec 2000, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: Anyone know of a good bigint/bigfloat library whose terms are such that we can just snag the source and use it in perl? There was some traffic on gcc list recently about a GNU one (presumably GPL only). There's a clone of the GPL one that was written specifically to avoid GPL issues. I'll try to dig up more references when I'm in next week. Cool, thanks. If the licensing issues are good, I'll take a shot at redoing BigInt and BigFloat for perl 5 as a trial run. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
Yeak, I know a lot of the old 8 and 16 bit chips are in use as control devices places. Those are the ones I'm thinking about. (Not that hard, but I don't want to rule them out needlessly) Yeah! I want to dust off my trusty old Z80 boxes :-) On a more serious note: recently a company announced to have a JVM for 8-bit CPUs. So we should scoff at the idea, either. http://industry.java.sun.com/javanews/stories/story2/0,1072,32628,00.html -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS That's good. Though do either of them have 16-bit data busses? DSPs are more messy. DS That's probably a bit too specialized a piece of hardware to worry DS about. Unlss things have changed lately, they're not really DS general-purpose CPUs. some are fairly close to that. they are more like general cpu's with specialized int/float multiply/add sections in some ways. i have seen complex apps (with dsp built in) programmed on them. one did a modular OS type thing for telephony (you could connect modules and things together on the fly) which had as much general programming as dsp on the same system. cell phones can use their dsp for both signal stuff and control and UI. so don't rule dsp's out just yet. they are closer to the common 32 bit cpu than the microcontrollers in many ways. It is micro-controllers that you have to worry about DS Yeak, I know a lot of the old 8 and 16 bit chips are in use as DS control devices places. Those are the ones I'm thinking DS about. (Not that hard, but I don't want to rule them out DS needlessly) some of the 8 bitters would be imposible to code perl on as they have fixed rom/ram of very small sizes, like under a few k. :) e.g. you don't need much code/ram to run a microwave oven. and that is where the volume really is and i doubt perl will ever want to penetrate that market. 16 bitters are not much different but some have decent memory sizes depending on the model of the chip. many have fancy I/O subsystems on board which would be painful for perl to handle. (that is another story, how to make perl do i/o register access better). again i don't think these are areas people are clamoring for perl to run on. maybe some of us should go to an rtos/embedded show and ask around "how often is perl requested?" in network controllers (linksys type things) and other embedded stuff in that world, perl has requested. i have seen support mentioned for vxworks, psos and and maybe othe rtos systems. that is more of an OS problem than a chip one. gcc is used on almost all those systems so perl would compile ok i would guess. now most of my info is about 3 years old (from when i was working on an rtos system). some sort of market survey, reading the trades, asking a few suppliers, etc. should be done before we expend any major amount of energy working on these platforms. there is a perl embedded list. is it active? are any of us on it? we can just email them to get some up to date info. they aleady like perl. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: maybe some of us should go to an rtos/embedded show and ask around "how often is perl requested?" JH Perl already exists for QNX, though of course QNX most often runs on x86s. JH Some might consider EPOC to be an embedded OS (running on ARMs). But I JH have had Perl requested for VxWorks (and of course PalmOS, and PocketPC JH formely known as WinCE). i have heard it runs on qnx. and the requests for palmos are known. wince is my favorite name for a product i have ever seen. i have heard you could/would be severely punished (fired? fined?) for referring to wince by that name inside redmond. one reason i suspected they changed the name. the biggest sales win was with att tv cable boxes only after redmond bought $5B (that's a B) of att stock. JH An OS problem and a build environment (cross-compilation, yuk) JH problem. I once managed to compile miniperl (5.005) for Chorus. JH I'm about to unearth the cross-compilation changes I had to make to JH get that working. (You thought Configure was hairy enough already? JH Think again: the test executables have transfered to and run on the JH target platform, and the results shipped back to the build platform JH (where Configure is running)) ouchie! but you seem to agree that porting to most embedded type systems is more of an OS (and testing!) issue than compilation. if other complex enough software runs on it, perl could (and should?). the hardware is not the limiting factor, it is the OS platform that is. this include DSP's and microcontrollers. one point we have mentioned but should be repeated is making the core internals sufficiently modular that you can skip large chunks (string eval!) when needed for certain platforms. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: JH An OS problem and a build environment (cross-compilation, yuk) JH problem. I once managed to compile miniperl (5.005) for Chorus. JH I'm about to unearth the cross-compilation changes I had to make to JH get that working. (You thought Configure was hairy enough already? JH Think again: the test executables have transfered to and run on the JH I forgot: also the input files need to transferred to the target. try porting a BSD 4.1 kernel and utils to a prototype cpu card, all over a single serial line. this started with burning roms! :) JH I think there are true limits imposed by the more limited CPUs JH like address space. I think there might be nasty assumptions one JH easily makes that work only on 32-bit or more address spaces. well, i said that too. most (by volume shipped) real world embedded controllers are dinky and inside your microwave, etc. they are meant to be as cheap as possible, and have minimal ram/rom. perl is not possible on them at all. the larger ones which run a proper RTOS could be targeted for perl. so my point was that if the RTOS was decent/powerful enough, perl should be able to be ported. hence qnx supporting it so easily, but vxworks is not fully done. some combinations of RTOS and cpu may be trickier or impossible. we can make perl6 work out of the box for vxworks for many chips IMO. we just have to keep it modular and trim for these platforms. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: That's fine. I was thinking of smaller processors that might be used in embedded apps and such. (I'm also not sure what's the most efficient integer representation on things like the ARM microprocessors are) ARM7/ARM9 are both 32-bit MIPS has both 32-bit and 64-bit variants. That's good. Though do either of them have 16-bit data busses? Not at the CPU no - what happens at chip boundary depends on what customer asks for. The 68XXX in Palm-Pilots are the issue there. DSPs are more messy. That's probably a bit too specialized a piece of hardware to worry about. Unlss things have changed lately, they're not really general-purpose CPUs. Some of them are. It is micro-controllers that you have to worry about Yeak, I know a lot of the old 8 and 16 bit chips are in use as control devices places. Those are the ones I'm thinking about. (Not that hard, but I don't want to rule them out needlessly) I suspect that any that are up to running anything approximating perl will have 32-bit ops in a library in any case. -- Nick Ing-Simmons
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: Anyone know of a good bigint/bigfloat library whose terms are such that we can just snag the source and use it in perl? There was some traffic on gcc list recently about a GNU one (presumably GPL only). I don't really care to write the code for division, As I recall Knuth has something on it. I know that some hardware FPUs do division (N/M) by Newton-Raphson expansion of 1/M and then do N*(1/M). let alone the transcendental math ops... TI's sources for those site some book or other. The snag with those and sqrt() etc. is that the published algorithms "know" how many terms of power series are needed to reach (say) IEEE-754 "double". Thus a "big float" still needs to decide how precise it is going to be or atan2(1,1)*4 (aka PI) is going to take a while to compute... -- Nick Ing-Simmons
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: I'm reasonably certain that all platforms that perl will ultimately run on can muster hardware support for 16-bit integers. Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - they have a tendency to widen to 32-bits. That's fine. I was thinking of smaller processors that might be used in embedded apps and such. (I'm also not sure what's the most efficient integer representation on things like the ARM microprocessors are) ARM7/ARM9 are both 32-bit MIPS has both 32-bit and 64-bit variants. DSPs are more messy. It is micro-controllers that you have to worry about -- Nick Ing-Simmons
Re: standard representations
On Sat, 30 Dec 2000, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: Anyone know of a good bigint/bigfloat library whose terms are such that we can just snag the source and use it in perl? There was some traffic on gcc list recently about a GNU one (presumably GPL only). There's a clone of the GPL one that was written specifically to avoid GPL issues. I'll try to dig up more references when I'm in next week. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: Strings can be of three types--binary data, platform native, and UTF-32. No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. I don't understand that in the light of supporting "platform native". That could easily be any of those as you note below. So what operations are supported on "platform native" strings? Are we at the mercy of locale's idea of upper/lower case, sort order etc.? Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. -- Nick Ing-Simmons
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: I'm reasonably certain that all platforms that perl will ultimately run on can muster hardware support for 16-bit integers. Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - they have a tendency to widen to 32-bits. I also expect that they can all muster at least software support for 32-bit integers. However The issue isn't support, it's efficiency. Since we're not worrying about loss of precision (as we will be upconverting as needed) the next issue is speed, and that's where we want things to be in a platform convenient size. I honestly can't think of any reason why the internal representation of an integer matters to the outside world, but if someone can, do please enlighten me. :) I can't think of anything except the range that is affected by the representation. -- Nick Ing-Simmons
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] writes: BigInt and BigFloat are both pure perl, and as such their speed leaves a *lot* to be desired. Fixing that (at least yanking some of it to XS) has been on my ToDo list for a while, but other stuff keeps getting in the way... :) My own "evolutionary" view of things is that if we did XS versions of BigInt and BigFloat for perl5 we would learn some issues that might affect Perl6. i.e. the vtable entries for "ints" may be influenced by their use as building blocks for "floats". For example the choice of radix in the BigInt case - should it be N*16-bits or should we try and squeeze 32-bits - or to avoid issues with sign should that be 15 or 31? (If we assume we use 2's complement then LS words are treated as unsigned only MS word has sign bit(s).) BigFloat could well build on BigInt for its "mantissa" and have another int-of-some-kind as its exponent. We don't need to pack it tightly so we should probably avoid IEEE-like hidden MSB. The size of exponent is one area where "known range of int" is important. -- Nick Ing-Simmons
Re: standard representations
At 12:56 PM 12/29/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: Strings can be of three types--binary data, platform native, and UTF-32. No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. I don't understand that in the light of supporting "platform native". That could easily be any of those as you note below. I'm crossing my fingers and hoping for fixed-width representations, honestly. I think it's in vain, though. :( So what operations are supported on "platform native" strings? For fixed-width ones, pretty much everything. For variable-width ones, at least native-UTF-32 and punt from there. (This is seeming less tenable as I think about it more) Are we at the mercy of locale's idea of upper/lower case, sort order etc.? Probably, yes. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: I'm reasonably certain that all platforms that perl will ultimately run on can muster hardware support for 16-bit integers. Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - they have a tendency to widen to 32-bits. That's fine. I was thinking of smaller processors that might be used in embedded apps and such. (I'm also not sure what's the most efficient integer representation on things like the ARM microprocessors are) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
At 01:15 PM 12/29/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: BigInt and BigFloat are both pure perl, and as such their speed leaves a *lot* to be desired. Fixing that (at least yanking some of it to XS) has been on my ToDo list for a while, but other stuff keeps getting in the way... :) My own "evolutionary" view of things is that if we did XS versions of BigInt and BigFloat for perl5 we would learn some issues that might affect Perl6. i.e. the vtable entries for "ints" may be influenced by their use as building blocks for "floats". I hadn't considered that as an idea, but most of the code would be useable, wouldn't it? I may move it up my ToDo ladder some. For example the choice of radix in the BigInt case - should it be N*16-bits or should we try and squeeze 32-bits - or to avoid issues with sign should that be 15 or 31? (If we assume we use 2's complement then LS words are treated as unsigned only MS word has sign bit(s).) I like the idea of n-1 bit integers building this up to make carry/borrow detection easier. If we were at a lower level I'd check the math error status bit directly, but we can't do that. :( (And I, for one, don't care to hand-roll assembly at this point, certainly not for RISC processors...) BigFloat could well build on BigInt for its "mantissa" and have another int-of-some-kind as its exponent. We don't need to pack it tightly so we should probably avoid IEEE-like hidden MSB. The size of exponent is one area where "known range of int" is important. That works too. Anyone know of a good bigint/bigfloat library whose terms are such that we can just snag the source and use it in perl? I don't really care to write the code for division, let alone the transcendental math ops... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Anyone know of a good bigint/bigfloat library whose terms are such DS that we can just snag the source and use it in perl? I don't DS really care to write the code for division, let alone the DS transcendental math ops... well, people have mentioned ruby has a fast version of those. i would imagine its license is compatible with perl but IANAL (hey, i used that for the first time since i learned it at the first perl quiz show and didn't know it). not that it would help much, but many eons ago i wrote a packed decimal math library for PL/I. i was taught a trick (excess 3) where you use 32 bit integer math and shifts to do adds very quickly. everything else sat on top of add. :). i would imagine bigint would be similar in some ways. regarding bigfloat, i can see both the mantissa and the exponent growing. i seem to get from this thread that the exponent does has a max value of some large int (32 bits?). is this a reasonable limitation? it does seem kinda large having a max exponent in the billions. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
Daniel Chetlin [EMAIL PROTECTED] wrote:
What is it about automatic conversion to bigints (done well) that scares
you?
Well, consider the following perl5 code:
sub factorial {
my $n = shift;
my ($f,$i) = (1,0);
$f *= ++$i while $i $n;
$f;
}
Someone might be suprised and annoyed to find that when run under perl6,
it suddenly runs slowly and uses loads of memory.
I'd argue that at the language level there should be pragma allowing you
to choose between optimising for precison and optimising for speed/storage
(assuming these last two are synonymous).
If the default is speed/storage, then you get the perl5-ish behaviour of
int overflowing to float, and float overflowing to Infinity.
Under 'use precision' or whatever, ints overflow to bigints, floats
overflow to bigfloats etc.
Then everyone is happy. (Perhaps)
Re: standard representations
At 11:07 AM 12/28/00 +, David Mitchell wrote:
Daniel Chetlin [EMAIL PROTECTED] wrote:
What is it about automatic conversion to bigints (done well) that scares
you?
Well, consider the following perl5 code:
sub factorial {
my $n = shift;
my ($f,$i) = (1,0);
$f *= ++$i while $i $n;
$f;
}
Someone might be suprised and annoyed to find that when run under perl6,
it suddenly runs slowly and uses loads of memory.
On the other hand, they may well be happy that, for non-small versions of
$n, that it runs correctly. It doesn't take too many runs through before
you overflow the 53 bits most doubles get you.
I'd argue that at the language level there should be pragma allowing you
to choose between optimising for precison and optimising for speed/storage
(assuming these last two are synonymous).
If the default is speed/storage, then you get the perl5-ish behaviour of
int overflowing to float, and float overflowing to Infinity.
Under 'use precision' or whatever, ints overflow to bigints, floats
overflow to bigfloats etc.
That works for me--like I said, this is a language issue, so I'm not hugely
concerned with what it looks like as long as it gets dealt with. (That and
it becomes Larry's problem... :)
Then everyone is happy. (Perhaps)
Well, less unhappy, but I can live with that.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: standard representations
At 09:11 AM 12/28/00 -0800, Peter Buckingham wrote: Dan Sugalski wrote: And, unless Larry objects, I feel that all vtable methods should have the option of going with a 'scalar native' form if the operation if it's determined at runtime that two scalars are the same type, though this is optional and bay be skipped for cost reasons. (Doing it with, for example, complex numbers might be worth it, or when expensive conversions might be avoided) just a quick comment on complex numbers. i would have thought the idea would be to treat them as pairs? We will, and that's because they are. :) ie (Real Part, Imaginary Part). this would mean that the standard things that are being done for ints etc would also benefit complex numbers. the only things worth considering at this level might be ways of optimising pair operations for efficency? Anyway, i'm not sure that complex numbers is really an internals issue? If complex numbers are a fundamental data type that makes it an internals issue. Personally I'd like them to be, but not strongly enough to go too extreme with them. Support for complex constants and a full vtable implementation (possibly mostly or all in perl) would be good enough, and a good example of how to do it yourself. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
On Wed, 27 Dec 2000, Dan Sugalski wrote: As for types presented to extensions, we can certainly provide I8, I16, I32, and friends. But we can't guarantee that every platform has integral types of those sizes. For example, in perl5, I32 is sometimes 32 bits, and sometimes 64 bits. Some Crays simply don't have native 32-bit types. All integral types are 64 bits. So we can provide something called "I32" but we can't guarantee it's 32 bits. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Wed, 27 Dec 2000, Dan Sugalski wrote: I honestly can't think of any reason why the internal representation of an integer matters to the outside world, but if someone can, do please enlighten me. :) Passing parameters to library functions via extensions is tricky no matter how you do it. You must have a clear mapping between the types used in the library (e.g. int or void * or some POSIXy_t thingy) and the types used internally in Perl (e.g. IV). Currently we get away with being sloppy since I32 is almost always the same as int. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote: Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]: For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. I'm not sure about the wisdom of not making any guarrantees about int size, since that means that extensions have to go through the same hoops perl5 has, dealing with "unspecified" behaviors (cf. fun with ANSI stdio). To make life easy, we might want to ordain sizeof(p6int) = sizeof(void *) sizeof(p6int) = 4. Perl will (well, should at least) automagically upgrade to bigints if a regular int overflows (Assuming that conversion's not been forbidden by a particular variable), so that's not going to be an issue inside variables. As for types presented to extensions, we can certainly provide I8, I16, I32, and friends. On the other hand, this makes a port of the PVM to Palms and the like somewhat harder (but would it be much easier to wedge them into the standard PVM?). Also, can we please mandate 2s-complement integral math? Perl 5 really always has, but can we please make it official? Why? For variables, math is math--2+2=4 regardless of whether you're one or two's complement, or BCD-encoded, or use the EBCDIC signed characters, or... Mandating representations seems rather too low-level to me, though if you've got a good argument I'm OK with it. For floats, we also have two types, C double and bigfloat. No guarantees to the size or accuracy of the double. bigfloats can be of any size. Floating point is even harder, and will require a lot of build-time checks anyway. The big issue I have with floats is that bigfloats will be more precise than regular floats/doubles, and so downconverting will lose data, which I don't like. Other than that, because floats should autoconvert like ints, I don't see any problem. (Not to say there isn't one, just that I don't see it... :) Strings can be of three types--binary data, platform native, and UTF-32. "platform native"? ASCII, EBCDIC, 16-bit chars, whatever. I'd rather not deal with variable-length characters at all, so things like UTF-8 and friends aren't really on the list. (Though they could be with the regex engine dealing with them in UTF-32 format) No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. The issue with UTF-32 is that we'd need to write an entire string-handling library, while quite a few modern platforms have _wstr* or equivalent. I'm not sure there's much in the way of string handling that we need to do that's not perl-specific. It's also not all that much work anyway and, while it is stuff we'll need to do, the benefits seem worth it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
On Mon, 25 Dec 2000, Dan Sugalski wrote: For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. So a native int could be 8 bits big? I think that's allowed according to ANSI. Not very useful, though. What's the point of having a native int if nothing is known about it? You can't reliably use it for numbers above 100, then (or even if "at least 16 bits" is guaranteed, you can't portably use it for numbers bigger than 32000-odd). This is assuming that larger numbers automatically fail-over to bigint, otherwise, for portability, one would probably be better off using bigints all the time. Cheers, Philip -- Philip Newton [EMAIL PROTECTED] I appreciate copies of replies to messages I sent to Perl 6 lists.
Re: standard representations
At 10:46 AM 12/27/00 -0500, Philip Newton wrote: On Mon, 25 Dec 2000, Dan Sugalski wrote: For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. So a native int could be 8 bits big? Yup, if that's what the platform does. It's up to the port folks for that platform to decide that. I think that's allowed according to ANSI. Not very useful, though. What's the point of having a native int if nothing is known about it? Speed. And, generally, something is known about it. You can't reliably use it for numbers above 100, then (or even if "at least 16 bits" is guaranteed, you can't portably use it for numbers bigger than 32000-odd). This is assuming that larger numbers automatically fail-over to bigint, otherwise, for portability, one would probably be better off using bigints all the time. If you're writing perl code targeted to an 8-bit platform (assuming perl ever runs on such a beast) you will take special care, I can guarantee it. And odds are you're not worried about portability either. When dealing with 'small' platforms (8 and 16 bit systems) you have to keep the limitations of your system firmly in mind no matter what you're doing. (Having worked up from 8 bit machines, it's my feeling that you really can't start ignoring things until you hit 32 bitness) Portability is just not nearly as much of an issue as speed in these cases. And, of course, if you *were* managing a port for an 8 or 16 bit machine, the alternative (32 bit and bigint) means emulating *all* integer ops, not just some of them. Ick. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote: Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]: For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. I'm not sure about the wisdom of not making any guarrantees about int size, since that means that extensions have to go through the same hoops perl5 has, dealing with "unspecified" behaviors (cf. fun with ANSI stdio). To make life easy, we might want to ordain sizeof(p6int) = sizeof(void *) sizeof(p6int) = 4. Perl will (well, should at least) automagically upgrade to bigints if a regular int overflows (Assuming that conversion's not been forbidden by a particular variable), so that's not going to be an issue inside variables. As for types presented to extensions, we can certainly provide I8, I16, I32, and friends. On the other hand, this makes a port of the PVM to Palms and the like somewhat harder (but would it be much easier to wedge them into the standard PVM?). Also, can we please mandate 2s-complement integral math? Perl 5 really always has, but can we please make it official? Why? For variables, math is math--2+2=4 regardless of whether you're one or two's complement, or BCD-encoded, or use the EBCDIC signed characters, or... Mandating representations seems rather too low-level to me, though if you've got a good argument I'm OK with it. Mostly because it seems to be a requirement for intelligent integer-preserving maths (cf. PERL_PRESERVE_IVUV in perl5). For floats, we also have two types, C double and bigfloat. No guarantees to the size or accuracy of the double. bigfloats can be of any size. Floating point is even harder, and will require a lot of build-time checks anyway. The big issue I have with floats is that bigfloats will be more precise than regular floats/doubles, and so downconverting will lose data, which I don't like. Other than that, because floats should autoconvert like ints, I don't see any problem. (Not to say there isn't one, just that I don't see it... :) My question here is whether each supported platform is going to need to provide its own overflow detection/autoconversion decision routines, since the portable part of perl6 will have now idea how far it can go with native numbers. Strings can be of three types--binary data, platform native, and UTF-32. "platform native"? ASCII, EBCDIC, 16-bit chars, whatever. I'd rather not deal with variable-length characters at all, so things like UTF-8 and friends aren't really on the list. (Though they could be with the regex engine dealing with them in UTF-32 format) But why is perl6 messing with them, since it has no idea what they mean? No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. The issue with UTF-32 is that we'd need to write an entire string-handling library, while quite a few modern platforms have _wstr* or equivalent. I'm not sure there's much in the way of string handling that we need to do that's not perl-specific. It's also not all that much work anyway and, while it is stuff we'll need to do, the benefits seem worth it. The only issue is that the CRTL's versions may be in hand-tuned assembler, and perl6 will be doing a _lot_ of strlen()s, I expect. But with good compilers, I suppose, its an open question on how much performance one really gains from hand assembly. -- BKS __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: standard representations
At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote: Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]: For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. I'm not sure about the wisdom of not making any guarrantees about int size, since that means that extensions have to go through the same hoops perl5 has, dealing with "unspecified" behaviors (cf. fun with ANSI stdio). To make life easy, we might want to ordain sizeof(p6int) = sizeof(void *) sizeof(p6int) = 4. Perl will (well, should at least) automagically upgrade to bigints if a regular int overflows (Assuming that conversion's not been forbidden by a particular variable), so that's not going to be an issue inside variables. As for types presented to extensions, we can certainly provide I8, I16, I32, and friends. On the other hand, this makes a port of the PVM to Palms and the like somewhat harder (but would it be much easier to wedge them into the standard PVM?). Also, can we please mandate 2s-complement integral math? Perl 5 really always has, but can we please make it official? Why? For variables, math is math--2+2=4 regardless of whether you're one or two's complement, or BCD-encoded, or use the EBCDIC signed characters, or... Mandating representations seems rather too low-level to me, though if you've got a good argument I'm OK with it. Mostly because it seems to be a requirement for intelligent integer-preserving maths (cf. PERL_PRESERVE_IVUV in perl5). Fair enough, though I'm not convinced it's enough to mandate it. I'm not sure if there are any non-two's complement machines out there anymore, anyway, since it makes the hardware design easier. (I know some machines, like the System/3x0 family and various VAXen have string math instructions as add-ons, but that falls into the bigint category not in the core integer support) For floats, we also have two types, C double and bigfloat. No guarantees to the size or accuracy of the double. bigfloats can be of any size. Floating point is even harder, and will require a lot of build-time checks anyway. The big issue I have with floats is that bigfloats will be more precise than regular floats/doubles, and so downconverting will lose data, which I don't like. Other than that, because floats should autoconvert like ints, I don't see any problem. (Not to say there isn't one, just that I don't see it... :) My question here is whether each supported platform is going to need to provide its own overflow detection/autoconversion decision routines, since the portable part of perl6 will have now idea how far it can go with native numbers. Yes, they will. Each chip family, at least. I'm thinking we'll have a generic CHECK_OVERFLOW macro that's redefined on a per-CPU basis and handled by whoever's doing the port for that system, with some generic fall-back code. All the CPUs I have experience with can autodetect this, though it's an odd set. (VAX, Alpha, 6502, 680x0, 880x0, and System/3x0 series chips) I don't know if Sparc, MIPS, ARM, or x86 do it, but I'd assume so. Yeah, it means some assembly for speed, but I'm OK with that. Strings can be of three types--binary data, platform native, and UTF-32. "platform native"? ASCII, EBCDIC, 16-bit chars, whatever. I'd rather not deal with variable-length characters at all, so things like UTF-8 and friends aren't really on the list. (Though they could be with the regex engine dealing with them in UTF-32 format) But why is perl6 messing with them, since it has no idea what they mean? But it does, though--the character constant 'A' becomes *something* on each platform. Might be 8-bit ASCII or EBCDIC, might be some 16-bit wide character, might be UTF-8. Who knows, but the underlying runtime library for the platform can manage it, and if it can't, then whoever's managing the port can fall back to whatever they like. No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. The issue with UTF-32 is that we'd need to write an entire string-handling library, while quite a few modern platforms have _wstr* or equivalent. I'm not sure there's much in the way of string handling that we need to do that's not perl-specific. It's also not all that much work anyway and, while it is
Re: standard representations
On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote: So a native int could be 8 bits big? I think that's allowed according to ANSI. ANSI/ISO C states: char = short = int = long char = 8 bits short = 16 bits int = 16 bits long = 32 bits C99 adds "long long", which is = long, and is at least 64 bits large. I'd be in favor of defining Perl's "native int" type to be at least 32 bits long. I would recommend against using the compiler's default int type in all cases, as there are compilers which define int as 16 bits for backwards compatability reasons. (As opposed to 16 bits being the native word size of the architecture.) - Damien
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Our integers will be generally unbounded in size--what I want is DS for the platform people to have the option of choosing a fast DS version of integer scalars that can be used when appropriate, and DS switching to the slower bigint version when things over or DS underflow. that made sense to me originally. but why over/underflow to bigint? what if i wanted the current semantics of going to float? floats will be much faster than bigint. how would i force a var to float then? i don't recall these semantics being hashed out in the rfc phase. and for sure we know larry has not annointed them yet. :) i know some want the bigint overflow but i think there should be a way (pragma) to control it. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote: I don't recall the bit sizes to be in ANSI C. Which paragraph is that in? You need to deduce the bit sizes, as the standard doesn't speak in terms of bits. I don't have a copy of C89 available, but section 5.2.4.2.1 defines the sizes of the various integers: -- minimum value for an object of type short int SHRT_MIN-32767 // -(2 ** 15 - 1) -- maximum value for an object of type short int SHRT_MAX+32767 // 2 ** 15 - 1 ...and so forth. Even so, the fact that a standard may declare it, doesn't make it true. I would expect embedded targets to differ from this. I seriously doubt Perl will ever run on an architecture too small to provide a 32-bit type. I am certain it will never run on an architecture with no 16-bit type. Furthermore, the fact that the standard declares a thing DOES make it true. If Perl is to be written in C, it makes sense that it require a compiler which at least pretends to conform to ANSI/ISO C. This is hardly an onerous restriction -- most compilers are compliant, with the exception of compilers for very-small embedded systems (ones where the total memory available is measured in bytes) and antiquated curiosities like the SunOS 4 compiler. Can you name specific compilers which fail to conform to the standard in this (or other) regards, which Perl will need to support? That's eskewing efficiency to make sensible minimum guarantees. I'd personally rather see the C compiler's native types be used, because that's what the platform can do _efficiently_. Using larger types than that harms perl's ability to perform well on small platforms. I am deeply dubious about Perl's ability to perform well on 80286 (or equivalent capacity) machines under any circumstances. - Damien
Re: standard representations
Damien Neil wrote: On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote: I don't recall the bit sizes to be in ANSI C. Which paragraph is that in? You need to deduce the bit sizes, as the standard doesn't speak in terms of bits. I don't have a copy of C89 available, but section 5.2.4.2.1 defines the sizes of the various integers: -- minimum value for an object of type short int SHRT_MIN-32767 // -(2 ** 15 - 1) -- maximum value for an object of type short int SHRT_MAX+32767 // 2 ** 15 - 1 ...and so forth. Even so, the fact that a standard may declare it, doesn't make it true. I would expect embedded targets to differ from this. I seriously doubt Perl will ever run on an architecture too small to provide a 32-bit type. I am certain it will never run on an architecture with no 16-bit type. This seems likely, but we must take care not to take these assumptions too far. For example, (and this is not realted to this discussion), pointers may well be smaller than integers (MVS defines 32-bit ints and 31-bit pointers) Furthermore, the fact that the standard declares a thing DOES make it true. If Perl is to be written in C, it makes sense that it require a compiler which at least pretends to conform to ANSI/ISO C. This is hardly an onerous restriction -- most compilers are compliant, with the exception of compilers for very-small embedded systems (ones where the total memory available is measured in bytes) and antiquated curiosities like the SunOS 4 compiler. I have far less trust in the standards than you have. Having said that, I can't actually name non-compliant compilers, so you're quite likely to be right. Can you name specific compilers which fail to conform to the standard in this (or other) regards, which Perl will need to support? That's eskewing efficiency to make sensible minimum guarantees. I'd personally rather see the C compiler's native types be used, because that's what the platform can do _efficiently_. Using larger types than that harms perl's ability to perform well on small platforms. I am deeply dubious about Perl's ability to perform well on 80286 (or equivalent capacity) machines under any circumstances. I sure would like it to still work, though. On a tiny platform, I'd rather have a slow and mimimalistic perl, than no perl at all. If a drive for efficiency on larger platforms would preclude the use of perl on such tiny systems (and your proposal doesn't), that would be bad. Hildo
Re: standard representations
On Wed, Dec 27, 2000 at 02:51:57PM -0500, Hildo Biersma wrote: This seems likely, but we must take care not to take these assumptions too far. For example, (and this is not realted to this discussion), pointers may well be smaller than integers (MVS defines 32-bit ints and 31-bit pointers) This is exactly the reason why standards are important. An architecture with 32-bit ints and 31-bit pointers is completely valid, and it is important to not write code which assumes that ints and pointers are interchangable. I have far less trust in the standards than you have. Having said that, I can't actually name non-compliant compilers, so you're quite likely to be right. Most compilers will violate the standard in certain small ways; complete conformance is an ideal rarely (if ever) reached. Few compilers (and none, in my experience, of any quality) will commit gross violations such as getting the guaranteed integer sizes wrong. - Damien
Re: standard representations
At 02:15 PM 12/27/00 -0500, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Our integers will be generally unbounded in size--what I want is DS for the platform people to have the option of choosing a fast DS version of integer scalars that can be used when appropriate, and DS switching to the slower bigint version when things over or DS underflow. that made sense to me originally. but why over/underflow to bigint? what if i wanted the current semantics of going to float? floats will be much faster than bigint. how would i force a var to float then? I don't know yet. Pragma or attribute on a variable (depending on whether it was an occasional or common thing) would be my bet. Going floating point would definitely be a win over going bigint, though I don't know if there are precision loss checks in most FPUs. i don't recall these semantics being hashed out in the rfc phase. and for sure we know larry has not annointed them yet. :) The semantics haven't been set down either from a perl or internals standpoint yet. Perl level is Larry's problem, internals is ours. Luckily they can be hammered out mostly independently. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS The semantics haven't been set down either from a perl or internals DS standpoint yet. Perl level is Larry's problem, internals is ours. Luckily DS they can be hammered out mostly independently. i can see things changing very easily. but to me, how perl handles overflow is a language semantic as much as implementation. in 5 it is well defined (ilya not withstanding) and you are talking bigint stuff which scares me. i don't think that should be the default in any case. i would want my perl numbers to be float or ints and bring in bigint as you said by pragma or attribute. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
At 11:21 AM 12/27/00 -0800, Damien Neil wrote: On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote: I seriously doubt Perl will ever run on an architecture too small to provide a 32-bit type. I am certain it will never run on an architecture with no 16-bit type. I'm reasonably certain that all platforms that perl will ultimately run on can muster hardware support for 16-bit integers. I also expect that they can all muster at least software support for 32-bit integers. However The issue isn't support, it's efficiency. Since we're not worrying about loss of precision (as we will be upconverting as needed) the next issue is speed, and that's where we want things to be in a platform convenient size. I honestly can't think of any reason why the internal representation of an integer matters to the outside world, but if someone can, do please enlighten me. :) Furthermore, the fact that the standard declares a thing DOES make it true. If Perl is to be written in C, it makes sense that it require a compiler which at least pretends to conform to ANSI/ISO C. This is hardly an onerous restriction -- most compilers are compliant, with the exception of compilers for very-small embedded systems (ones where the total memory available is measured in bytes) and antiquated curiosities like the SunOS 4 compiler. The issue isn't compliance, it's efficiency. gcc gets you 64-bit integer ops on x86 machines, but that doesn't make them efficient... Can you name specific compilers which fail to conform to the standard in this (or other) regards, which Perl will need to support? It wouldn't at all surprise me if a number of embedded platforms like 16-bit integers best. I couldn't name one for you, that not being my area of expertise, but since I haven't yet seen a reason why they should be excluded (at least not one that works for me) I'm not willing to not do it. Things also cut the other way--there are, or may be soon, platforms for which you want 64 or 128 bit integers, so if we're not stopping things on the high end, I don't see a reason to stop them on the low. That's eskewing efficiency to make sensible minimum guarantees. I'd personally rather see the C compiler's native types be used, because that's what the platform can do _efficiently_. Using larger types than that harms perl's ability to perform well on small platforms. I am deeply dubious about Perl's ability to perform well on 80286 (or equivalent capacity) machines under any circumstances. I'm not. I can see perl performing rather well in a number of smaller systems if bits of the interpreter are tuned for the platform. (Like rewriting pieces in assembly, for example) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
On Wed, Dec 27, 2000 at 04:08:00PM -0500, Uri Guttman wrote:
i can see things changing very easily. but to me, how perl handles
overflow is a language semantic as much as implementation. in 5 it is
well defined (ilya not withstanding) and you are talking bigint stuff
which scares me. i don't think that should be the default in any case. i
would want my perl numbers to be float or ints and bring in bigint as
you said by pragma or attribute.
Which of these two behaviors do you find more useful:
[~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c'
7.25741561530799e+306
[~] $ perl -le'$c=1;$c*=$_ for (2..171);print $c'
inf
(The following are wrapped lines -- they come out all in one line
originally)
[~] $ ruby -e'c=1;(1..170).each{|i| c *= i};p c'
725741561530799896739672821112926311471699168129645137654357779890056-
18434017061578523507492426174595114909912378385207702256544275302-
532890077320751090240043028005829560396661259965825710439855829425756-
8966313439612262571094946806711205568880457193340212661452800-
000
[~] $ ruby -e'c=1;(1..1500).each{|i| c *= i};p c'
snipped 4115 digits for brevity
Oh, and in case you're wondering, both of the Ruby commands are *fast*.
As compared to our core module, Math::BigInt, which is slower than
molasses even after you bother to `use' it, deal with the interface, and
do things by hand.
What is it about automatic conversion to bigints (done well) that scares
you?
-dlc
Re: standard representations
At 01:48 PM 12/27/00 -0800, Damien Neil wrote: On Wed, Dec 27, 2000 at 04:17:21PM -0500, Dan Sugalski wrote: The issue isn't support, it's efficiency. Since we're not worrying about loss of precision (as we will be upconverting as needed) the next issue is speed, and that's where we want things to be in a platform convenient size. I think I've managed to argue myself around into a position I didn't intend to take. : I'm not particularly arguing for Perl using any given size of integer. My initial point was just that you are allowed to assume that there will be 16- and 32-bit ints available if you want them. I'm a C standard weenie, and I tend to be picky about the language. Fair enough. I'm looking at things from another angle, since perl's use of C is an accident of implementation. :) I'm trying to make sure we don't lock ourselves in--it may be handy (and probably likely) for bits of at least some implementations of perl to be in other languages. On a secondary note, I would prefer to be able to assume at least 32 bits worth of precision in a default Perl scalar -- if this happens by magical upconversion into bigints, that's fine by me! Keen then. I'd say we're set. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
"DC" == Daniel Chetlin [EMAIL PROTECTED] writes: DC Which of these two behaviors do you find more useful: DC [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c' DC 7.25741561530799e+306 DC [~] $ perl -le'$c=1;$c*=$_ for (2..171);print $c' DC inf i am not worried about those conditions. it is just a case of specifying things cleanly. if the default is overflow to bigint, then how would you get back to regular ints? or go between int and float? it just isn't clear to me but then i can be very foggy. DC Oh, and in case you're wondering, both of the Ruby commands are *fast*. DC As compared to our core module, Math::BigInt, which is slower than DC molasses even after you bother to `use' it, deal with the interface, and DC do things by hand. that just means we need a better bigint implementation then the perl5 module (maybe we could steal ruby's? :). and i agree it should be tightly integrated in the core with the vtable stuff. it is just the semantics of overflow and conversion that are not well specified IMO. this is the kind of thing that should have been fought out in the rfc wars. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
At 06:15 PM 12/27/00 -0500, Uri Guttman wrote: "DC" == Daniel Chetlin [EMAIL PROTECTED] writes: DC Which of these two behaviors do you find more useful: DC [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c' DC 7.25741561530799e+306 DC [~] $ perl -le'$c=1;$c*=$_ for (2..171);print $c' DC inf i am not worried about those conditions. it is just a case of specifying things cleanly. if the default is overflow to bigint, then how would you get back to regular ints? or go between int and float? it just isn't clear to me but then i can be very foggy. I'd like bigints to drop back to ints when they get small enough, but I'm not sure about the cost. Then again, given how pricey bigint math is, it's likely not much extra. As for the rest, perl should autoconvert as needed, unless a variable is pegged to be only one type. (Which is to say it should all be transparent, though specifying what and when's OK with me) DC Oh, and in case you're wondering, both of the Ruby commands are *fast*. DC As compared to our core module, Math::BigInt, which is slower than DC molasses even after you bother to `use' it, deal with the interface, and DC do things by hand. that just means we need a better bigint implementation then the perl5 module (maybe we could steal ruby's? :). and i agree it should be tightly integrated in the core with the vtable stuff. it is just the semantics of overflow and conversion that are not well specified IMO. this is the kind of thing that should have been fought out in the rfc wars. :) Well, nobody thought about it, and in the perl 5 style it's rightly in the 'implementation defined' area. Which is where we are now. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: standard representations
Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]: Okay, here's what I'm currently thinking of for standard representations of integers, numbers, strings, and (possibly) complex data. These are not necessarily indicative of how the data's stored in scalars (or hashes or arrays), merely the types that will need to be dealt with in the vtables. In addition to each of the types below, each vtable will have a 'same type' entry that'll be used if the optimizer can guarantee that the scalars involved in an operation are of the identical type. (Presumably things can be faster that way) For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. I'm not sure about the wisdom of not making any guarrantees about int size, since that means that extensions have to go through the same hoops perl5 has, dealing with "unspecified" behaviors (cf. fun with ANSI stdio). To make life easy, we might want to ordain sizeof(p6int) = sizeof(void *) sizeof(p6int) = 4. On the other hand, this makes a port of the PVM to Palms and the like somewhat harder (but would it be much easier to wedge them into the standard PVM?). Also, can we please mandate 2s-complement integral math? Perl 5 really always has, but can we please make it official? For floats, we also have two types, C double and bigfloat. No guarantees to the size or accuracy of the double. bigfloats can be of any size. Floating point is even harder, and will require a lot of build-time checks anyway. Strings can be of three types--binary data, platform native, and UTF-32. "platform native"? No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. The issue with UTF-32 is that we'd need to write an entire string-handling library, while quite a few modern platforms have _wstr* or equivalent. Finally, complex numbers, if we deal with them, will be either double or bigfloat complexes. (I don't see any reason to mess with integer versions, nor with mixed double/bigfloat types) And, unless Larry objects, I feel that all vtable methods should have the option of going with a 'scalar native' form if the operation if it's determined at runtime that two scalars are the same type, though this is optional and bay be skipped for cost reasons. (Doing it with, for example, complex numbers might be worth it, or when expensive conversions might be avoided) This part sounds good. Comments? I'm trying to balance out accuracy and DWIMmery with cost here, and I'm not 100% sure things are quite right yet. Dan -- BKS __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
standard representations
Okay, here's what I'm currently thinking of for standard representations of integers, numbers, strings, and (possibly) complex data. These are not necessarily indicative of how the data's stored in scalars (or hashes or arrays), merely the types that will need to be dealt with in the vtables. In addition to each of the types below, each vtable will have a 'same type' entry that'll be used if the optimizer can guarantee that the scalars involved in an operation are of the identical type. (Presumably things can be faster that way) For integers, we have two types, platform native, and bigint. No guarantees are made as to the size of a native int. bigints can be of any size. For floats, we also have two types, C double and bigfloat. No guarantees to the size or accuracy of the double. bigfloats can be of any size. Strings can be of three types--binary data, platform native, and UTF-32. No, we are not messing around with UTF-8 or 16, nor are we messing with EBCDIC, shift-JIS, or any of that stuff. Strings can be stored internally that way (and the native form might be one of them) but as far as the interface is concerned we have only three. Yes, this does mean if we mess with strings in UTF-8 format on a non-UTF-8 system they'll need to be fed out in UTF-32. It's bigger, but we can deal. Finally, complex numbers, if we deal with them, will be either double or bigfloat complexes. (I don't see any reason to mess with integer versions, nor with mixed double/bigfloat types) And, unless Larry objects, I feel that all vtable methods should have the option of going with a 'scalar native' form if the operation if it's determined at runtime that two scalars are the same type, though this is optional and bay be skipped for cost reasons. (Doing it with, for example, complex numbers might be worth it, or when expensive conversions might be avoided) Comments? I'm trying to balance out accuracy and DWIMmery with cost here, and I'm not 100% sure things are quite right yet. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
