John Macdonald <[EMAIL PROTECTED]> writes:
> If a int1 (or int2 or nybble or other sub-addressable sized value)
> is being referred to, a similar issue arises since most machines
> these days have byte addressing, but do not have bit addressing. If
> you can't refer directly to it, the value will have to be extracted
> and re-inserted to provide "is rw" access.
I surely must be misunderstanding what you're saying... the way I
read that, you're suggesting that it will matter to Perl -- not only
to the compiler but even to user code -- how the underlying hardware
addresses its memory. I really hope that's not the case.
I thought Parrot would take care of all that fiddly platform-dependent
stuff so that Perl doesn't have to know or care about it. Perl6 code
shouldn't have to even *know* whether it's running on a big or little
(or middle) endian system, how many bits wide the BUS is, how many
bits are in an integer, whether there's a math coprocessor, whether
the instruction set is RISC or CISC, how many CPUs there are, what
kind of filesystem the underlying OS has, or whether the underlying
GUI is Win32 or Aqua or GTK or Qt. Perl6 code shouldn't have to know
that stuff *even* to call libraries written in another language; even
the compiler shouldn't have to know about it. Parrot should have a
wrapper API thingydo that makes it Just Work.
That's the point of having a VM, or such was my understanding.
I don't think I'm dreaming the impossible here, because Inform seems
to manage this stuff just fine, with either of the VMs it compiles to
(except for the parts about calling libraries written in other
languages, and having a GUI; Inform doesn't support those things).
You can write the code and compile it on a DOS system, stick the
binary on an ftp server, and J. Random Nerd can download it, and
assuming he has the appropriate version of the VM for his system, it
will run your code -- whether his system is SPARC/Solaris or Nintendo
Gameboy, your code will never know the difference; as far as your code
is concerned, it's running on the z-machine. Parrot should be like
that (except that Parrot's minimum requirements for the underlying
system will have to be a little higher, because we want to support
things like disk I/O and allocating more RAM after the program starts
running).
So if the underlying hardware doesn't know how to write a single byte,
then Parrot should have workaround code for that. Perl shouldn't even
need to know about it.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
