> * Charles Forsyth wrote:
> > >waserror() depends on callee-save.
> >
> > caller-save, and a few other conventions (or rather, no need for more
> > conventions).
> > specifically, it's enough to save the pc and stack. all variables will
> > have the right values on non-zero return from setjmp,
* Charles Forsyth wrote:
> >waserror() depends on callee-save.
>
> caller-save, and a few other conventions (or rather, no need for more
> conventions).
> specifically, it's enough to save the pc and stack. all variables will
> have the right values on non-zero return from setjmp, regardless of
* Jens Staal wrote:
> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-hosting distro as the one you en
On Tue, 12 Jul 2011 19:09:44 +0100
Richard Miller <9f...@hamnavoe.com> wrote:
> > On
> > plan9 of course I don't pull from sources over my mobile phone,
> > instead pull and compile on the CPU server.
>
> Compiling on a phone is no longer so far-fetched. Compiling all
> of plan9port from scratch
> On
> plan9 of course I don't pull from sources over my mobile phone,
> instead pull and compile on the CPU server.
Compiling on a phone is no longer so far-fetched. Compiling all
of plan9port from scratch on a Nokia n900 takes about 1.5 hours.
It seems to be less hassle just to install gcc on t
Compiling should be called decompressing ;)
On Tue, 12 Jul 2011 02:10:50 +0200
hiro <23h...@googlemail.com> wrote:
> 2. compilers still running fastest on fast CPUs
I have a quad core I bought specifically for compiling, that was one of the
major tasks the box was going to do as I wanted to get more involved in Source
Mage GNU/Linux. It
On Mon, 11 Jul 2011 20:31:08 +0100
Charles Forsyth wrote:
> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?
Not the last time I tried, a couple of years ago.
I quite liked Gcc when it was at version 2.93
> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?
>
I'm not sure about gcc, but the go toolchain can produce quite well working
Plan 9 binaries.
Taru also has the go toolchain running native in itself after
Would the the work already done on the Plan9 binary format and
syscall mapping that has been made for the Glendix kernel be useful as
"documentation" for implementing a Plan9 binary output in GCC?
and in the other direction, would it be useful to make a Plan9 libc
port to compile "real" Plan9 bin
> it's true that network latency is a huge deal these days. and even a
> multicore
> machine looks like a bunch of fast cores connected to their l3 and each
> other
> by a slow network. but if you have a "large enough" packet of work, it can
> make
> sense to move it over to another cpu. i don't
setting up cross-compilation with gcc, and even using it once set up,
has historically been surprisingly complicated; has that changed?
>waserror() depends on callee-save.
caller-save, and a few other conventions (or rather, no need for more
conventions).
specifically, it's enough to save the pc and stack. all variables will
have the right values on non-zero return from setjmp, regardless of the
presence or absence of "volatile",
On Mon Jul 11 13:58:27 EDT 2011, 23h...@googlemail.com wrote:
> > I'd certainly like something where my local processes migrate from
> > my lower powered laptop including the Window manager migrate to a
> > more powerful CPU when it becomes available and back again when my
> > laptop becomes discon
> I'd certainly like something where my local processes migrate from my lower
> powered laptop including the Window manager migrate to a more powerful CPU
> when it becomes available and back again when my laptop becomes disconnected,
Here network latency is too high for such small tasks nowaday
> Notice though that the kernel and applications need
> some more that only the extensions. All of it (including the
> assembler) is written supposing caller save
> and other inner specifics of kencc that would need to be dealt with
> when compiling
> for gcc. It would be a port, not only a recompi
On Mon, Jul 11, 2011 at 6:41 PM, Jens Staal wrote:
> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-ho
Personally, I believe that a Plan9 target for a cross compiler might
be more interesting. GCC already added support for the Plan9 dialect
of C. If it also could be made to compile Plan9 binaries, it could be
used for an alternative self-hosting distro as the one you envisaged.
I am fully aware tha
Not to rain on anyone's summer of code project but I think producing a Linux
distro that runs on top of Plan 9 would be more beneficial to the Plan 9's
future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.
I've no problem with a kernel that could run both Plan 9 and Li
19 matches
Mail list logo