yep, molto bene.
On 11/16/09, lu...@proxima.alt.za lu...@proxima.alt.za wrote:
Anyway all that code is available.
What I want is the knowledge behind this code, it is a huge amount of
information that gets distilled into that code :-(
++L
Given the addition of this toolchain, one wonders how far we are from
being able to port all the P9 compilers to Linux and consequently to
all Posix platforms. My beef is that I have a wide choice of cross-
and native toolchains with which to port Plan 9 to a MIPS platform
(LSB), but I
I'd be very interested in an ELF based cross-compilation to plan9. I
have this many-core IA part that I would desperately love to boot a
nicer OS on than we currently have (memory footprint, scheduling, vm
architecture, syscall performance, remote exposure), but the principal
application
correct me if i am wrong. but isn't the usual MIPS calling convention to
store the return pc in R31?
Almost certainly.
you may just want to look at your compiler output. mips has various
branch and link commands that do a branch and put the returning pc
into R31, which is the usual
On Sun, Nov 15, 2009 at 9:26 AM, Paul Lalonde plalo...@telus.net wrote:
I'd be very interested in an ELF based cross-compilation to plan9. I have
this many-core IA part that I would desperately love to boot a nicer OS on
than we currently have (memory footprint, scheduling, vm architecture,
If there was a clear path, I might even be able to shake loose some
resources for it.
I'm thoroughly muddled up, but I'm not going to give up easily.
Between linuxemu, p9p and many bits from different directions, ELF
support and the eventual implementation of GCC/G++ is definitely
possible.
Anyway all that code is available.
What I want is the knowledge behind this code, it is a huge amount of
information that gets distilled into that code :-(
++L
* A ducktyping of sorts with interfaces and such. On the surface
it just saves
you a bunch of extends XXX, but it actually seems to bridge
the gap between
dynamically typed world and a statically typed one to an extent
that makes me
rethink whether static typed languages are as
On Fri, Nov 13, 2009 at 3:48 PM, Tim Newsham news...@lava.net wrote:
* A ducktyping of sorts with interfaces and such. On the surface
it just saves
you a bunch of extends XXX, but it actually seems to bridge
the gap between
dynamically typed world and a statically typed one to an
with a more complex type system that you cannot express in go. A
good, simple example is map. Go would need generics to support it.
$GOOROOT/src/pkg/bytes/bytes.go:248 func ToLower(s []byte) []byte
{ return Map(unicode.ToLower, s) }
I should have been more clear. I mean a generic map of
correct me if i am wrong. but isn't the usual MIPS calling convention to
store the return pc in R31?
you may just want to look at your compiler output. mips has various
branch and link commands that do a branch and put the returning pc
into R31, which is the usual calling convention.
Go has added a cat amongst the pigeons :-)
I'm a language aficionado and could not resist finding out more, but
what I found turned out to be relevant to me in additional ways: no
one has pointed out that the go toolchain is based on kenCC and
produces Linux-elf executables.
Given the addition
On Thu, Nov 12, 2009 at 8:34 PM, lu...@proxima.alt.za wrote:
Go has added a cat amongst the pigeons :-)
I'm a language aficionado
Makes two of us and I wouldn't mind comparing notes (in fact,
it would be quite helpful if all of us here at 9fans did). I wish I had
more time to devote to it,
On Thu, Nov 12, 2009 at 9:12 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
On Thu, Nov 12, 2009 at 8:34 PM, lu...@proxima.alt.za wrote:
Go has added a cat amongst the pigeons :-)
...
* A ducktyping of sorts with interfaces and such. On the surface
it just saves
you a bunch of
14 matches
Mail list logo
