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
