[9fans] AMD64 system

[9fans] AMD64 system

[Strake]

Hello all.

I just lately installed Plan 9, but the stock system is built for
32-bit x86, and I have an amd64 computer.

I found this diff: http://9legacy.org/9legacy/patch/nix.diff
which seems to have all needed system libraries, and its own kernel,
but the kernel seems to lack basic functionality, such as graphics and
mouse, and I can't find the local bootloader for it — the stock
bootloader chokes with message "bad kernel format", and on the nix web
site it says only to build pxe bootloader, which is not what I need.
It seems that nix is meant for cpu servers, not terminals. I need, if
my ken of 9jargon is not wrong, a terminal kernel.

In an earlier thread, "9vx instability", F. J. Ballesteros said this:
"Jim, Charles, and others made an excellent port for amd64 ... We used
that as a starting point for nix."
Is this the legendary amd64 port? Is it available?

I feel a bit lost. In the documentation, the authours emphasize its
portability, yet to actually build for another architecture seems
quite a bother, regrettably, since I was quite enthusiastic to use it
as my primary system.

Anyhow, I would be glad of any pointers to an amd64 port or
instructions to do same.

Cheers,
strake

Re: [9fans] AMD64 system

[Nemo]

nix does not have graphics yet. sorry. 
we are using a changed 9pxeload and
are switching to the new 9boot. 
the loader can be found in the distrib. 
if you can't wait. 

--
iphone kbd. excuse typos :)


On Apr 25, 2012, at 4:17 PM, Strake <strake888@gmail.com> wrote:

> Hello all.
> 
> I just lately installed Plan 9, but the stock system is built for
> 32-bit x86, and I have an amd64 computer.
> 
> I found this diff: http://9legacy.org/9legacy/patch/nix.diff
> which seems to have all needed system libraries, and its own kernel,
> but the kernel seems to lack basic functionality, such as graphics and
> mouse, and I can't find the local bootloader for it — the stock
> bootloader chokes with message "bad kernel format", and on the nix web
> site it says only to build pxe bootloader, which is not what I need.
> It seems that nix is meant for cpu servers, not terminals. I need, if
> my ken of 9jargon is not wrong, a terminal kernel.
> 
> In an earlier thread, "9vx instability", F. J. Ballesteros said this:
> "Jim, Charles, and others made an excellent port for amd64 ... We used
> that as a starting point for nix."
> Is this the legendary amd64 port? Is it available?
> 
> I feel a bit lost. In the documentation, the authours emphasize its
> portability, yet to actually build for another architecture seems
> quite a bother, regrettably, since I was quite enthusiastic to use it
> as my primary system.
> 
> Anyhow, I would be glad of any pointers to an amd64 port or
> instructions to do same.
> 
> Cheers,
> strake

Re: [9fans] AMD64 system

[Christoph Lohmann]

Greetings.

On Wed, 25 Apr 2012 16:31:42 +0200 Nemo <nemo@lsub.org> wrote:
> iphone kbd. excuse typos :)

Nix is running on iPhones?


Sincerely,

Christoph Lohmann

Re: [9fans] AMD64 system

[David du Colombier]

> I found this diff: http://9legacy.org/9legacy/patch/nix.diff
> which seems to have all needed system libraries, and its own kernel,
> but the kernel seems to lack basic functionality, such as graphics and
> mouse, and I can't find the local bootloader for it — the stock
> bootloader chokes with message "bad kernel format", and on the nix web
> site it says only to build pxe bootloader, which is not what I need.
> It seems that nix is meant for cpu servers, not terminals. I need, if
> my ken of 9jargon is not wrong, a terminal kernel.

You should use Erik Quanstrom's bootloader.

It is available here:

/n/sources/contrib/quanstro/root/sys/src/boot/pc-e820

Or here:

http://www.9legacy.org/9legacy/patch/boot-pc-e820.diff

-- 
David du Colombier

Re: [9fans] AMD64 system

[Nemo]

No. But sofware capable of using nix services is.
As you can see by looking at my signature in the previous mail.

Enjoy.

On Apr 25, 2012, at 4:31 PM, Christoph Lohmann wrote:

> Greetings.
>
> On Wed, 25 Apr 2012 16:31:42 +0200 Nemo <nemo@lsub.org> wrote:
>> iphone kbd. excuse typos :)
>
> Nix is running on iPhones?
>
>
> Sincerely,
>
> Christoph Lohmann
>

Re: [9fans] AMD64 system

[Ethan Grammatikidis]

On Wed, 25 Apr 2012 23:38:01 -0400
Russ Cox <rsc@swtch.com> wrote:

> On Wed, Apr 25, 2012 at 4:13 PM, Strake <strake888@gmail.com> wrote:
> > What the hell? This is a waste and a fault. long at least ought to be
> > at least a machine word.
>
> Use vlong.  Why does it matter what it's called?
>
> > The main one is this: I have a 64-bit machine, and I'll be damned if
> > my programs won't use every last one of them (^_~)
>
> They certainly won't.  The address space is really only 48 bits wide,
> and 47 for user space on most kernels.  Sorry to disappoint.
>
> More generally, you showed up demanding things and basically
> being a jerk.  People have explained the situation, you didn't pay
> anything for any of this, and we don't owe you anything.  If you're
> not happy about the state of the Plan 9 world, write some code
> or stop whining.
>
> Russ
>

Relax. I've been seeing this thread as a comedy since about the 10th
post or so.

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, Russ Cox <rsc@swtch.com> wrote:
> On Wed, Apr 25, 2012 at 4:13 PM, Strake <strake888@gmail.com> wrote:
>> What the hell? This is a waste and a fault. long at least ought to be
>> at least a machine word.
>
> Use vlong.  Why does it matter what it's called?

Not all programs that I use, I write.

>> The main one is this: I have a 64-bit machine, and I'll be damned if
>> my programs won't use every last one of them (^_~)
>
> They certainly won't.  The address space is really only 48 bits wide,
> and 47 for user space on most kernels.  Sorry to disappoint.

Machine words are nonetheless 64 bits wide.

> More generally, you showed up demanding things and basically
> being a jerk.

No. I demanded nothing. I simply said what I seek, and asked whether
it might be available. Clearly, it's not. I thought it might, since in
a prior thread there was vague reference to such. I never told anyone
to do it for me, and I never asked anyone to help me do it.

Some then asked me plainly what I need and why, so I responded; for
this, it seems, you call me jerk. My second message, I meant to be the
end of it. I said thanks for the link, and made some comments, which
were not imperative.

Some then asked me further questions, some of which asked me directly
what is wrong with X, for some X. When one asks me what is wrong with
X, I can only assume that one wishes to know my opinion on the matter,
so I declare it. Many were grievances against Plan 9 and its parts,
which I would otherwise keep to myself.

> People have explained the situation, you didn't pay
> anything for any of this, and we don't owe you anything.

All true. I never said otherwise.

> If you're
> not happy about the state of the Plan 9 world, write some code
> or stop whining.

I mean to do both.

Please remember what I said earlier:
I'd shut up if no one _asked_ me about it, but some did.

Please note this amendment: s/ if / iff /

Thanks to everyone who sent links to the amd64 bootloader and other help.

Cheers,
strake

Re: [9fans] AMD64 system

[andrey mirtchovski]

...but whining feels so righteous :(

Re: [9fans] AMD64 system

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

True story. If I wasn't on a phone i'd elaborate more.
On Apr 25, 2012 11:39 PM, "Russ Cox" <rsc@swtch.com> wrote:

> On Wed, Apr 25, 2012 at 4:13 PM, Strake <strake888@gmail.com> wrote:
> > What the hell? This is a waste and a fault. long at least ought to be
> > at least a machine word.
>
> Use vlong.  Why does it matter what it's called?
>
> > The main one is this: I have a 64-bit machine, and I'll be damned if
> > my programs won't use every last one of them (^_~)
>
> They certainly won't.  The address space is really only 48 bits wide,
> and 47 for user space on most kernels.  Sorry to disappoint.
>
> More generally, you showed up demanding things and basically
> being a jerk.  People have explained the situation, you didn't pay
> anything for any of this, and we don't owe you anything.  If you're
> not happy about the state of the Plan 9 world, write some code
> or stop whining.
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 1300 bytes --]

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, John Floren <john@jfloren.net> wrote:
> I thought you wanted this to do your uber computations, not watch movies?

No, I want this to do both! Likely not simultaneously.

> And if you have full-screen 3D games for Plan 9, share!

When I do, I shall.

> You still haven't told us your usage case. Wild speculation about what
> is possible, impossible, desirable, necessary, etc. is cheap on 9fans,
> I'm sure you've seen that.

Ah, the specifics, then:
* Browse the Web
* Read and write e-mail
* Write and build programs and libraries, mostly in C and Haskell:
Haskell compiler, VCS, various little utilites
* Build various other programs: kernels, compilers, Web browsers,
e-mail clients, window systems, others
* Encrypt and decrypt data: PGP, SSH, TLS
* Do symbolic computations: solve equations and such
* Do numeric computations: now light; potentially very heavy in near
future, e.g. computational fluid dynamics
* Potentially CAD: mechanical, if I ever find or write CADware not
grievous to use; and possibly electrical
* Play music
* Watch movies
* Play games: mostly first-person shooters, flight simulators, arcade games
* Typeset documents, mostly with LaTeX

I know that much that I wish to do is not yet feasible on stock P9,
but I hope to either do it myself or procrastinate until someone else
does (^_^)

Cheers,
strake

Re: [9fans] AMD64 system

[Russ Cox]

On Wed, Apr 25, 2012 at 4:13 PM, Strake <strake888@gmail.com> wrote:
> What the hell? This is a waste and a fault. long at least ought to be
> at least a machine word.

Use vlong.  Why does it matter what it's called?

> The main one is this: I have a 64-bit machine, and I'll be damned if
> my programs won't use every last one of them (^_~)

They certainly won't.  The address space is really only 48 bits wide,
and 47 for user space on most kernels.  Sorry to disappoint.

More generally, you showed up demanding things and basically
being a jerk.  People have explained the situation, you didn't pay
anything for any of this, and we don't owe you anything.  If you're
not happy about the state of the Plan 9 world, write some code
or stop whining.

Russ

Re: [9fans] AMD64 system

[John Floren]

On Wed, Apr 25, 2012 at 6:11 PM, Strake <strake888@gmail.com> wrote:
> On 25/04/2012, John Floren <john@jfloren.net> wrote:
>> Through the magic of compression, and other things like realizing that
>> you don't have to redraw the *entire* screen 60 times a second when
>> displaying a mostly-static desktop.
>> You just send the chunks that have
>> changed, *when* they change.
>
> And when watching full-screen video, or playing full-screen 3D games?
> Then it must redraw nearly the whole screen, nearly every frame.

I thought you wanted this to do your uber computations, not watch movies?

And if you have full-screen 3D games for Plan 9, share!

>> I'm not that familiar with how the Plan 9 graphics system works, but
>> we're not talking about hardware vs software OpenGL. There is no
>> OpenGL to be had here.
>
> Not yet. It seems to be in the works:
> http://plan9.bell-labs.com/wiki/plan9/todo/index.html
>
>> This is writing bits into a framebuffer and
>> having them appear on the screen. It's pretty damn fast to write
>> things to main memory.
>
> Yes, which works iff the video output is local. This I wrote in
> response to the idea that I make one machine a 64-bit devoted CPU
> server, which I doubt would be appropriate for my usage case and
> available hardware.
>

You still haven't told us your usage case. Wild speculation about what
is possible, impossible, desirable, necessary, etc. is cheap on 9fans,
I'm sure you've seen that.

john

Re: [9fans] AMD64 system

[andy zerger]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

And the link moved to somewhere like http://bellard.org/TinyGL/ ?
"L'eurreur de 404" at the plan9.bell link.

On Wed, Apr 25, 2012 at 7:21 PM, andrey mirtchovski
<mirtchovski@gmail.com>wrote:

> > Not yet. It seems to be in the works:
> > http://plan9.bell-labs.com/wiki/plan9/todo/index.html
>
> i think that work "stalled" in 2004 :)
>
>

[-- Attachment #2: Type: text/html, Size: 814 bytes --]

Re: [9fans] AMD64 system

[andrey mirtchovski]

> Not yet. It seems to be in the works:
> http://plan9.bell-labs.com/wiki/plan9/todo/index.html

i think that work "stalled" in 2004 :)

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, John Floren <john@jfloren.net> wrote:
> On Wed, Apr 25, 2012 at 1:30 PM, Strake <strake888@gmail.com> wrote:
>> On 25/04/2012, John Floren <john@jfloren.net> wrote:
>>> There are 3 options:
>>>
>>> 1. Suck it up and use the 64-bit system that is available
>>> 2. Write drivers for your hardware (this is the comedy option)
>>> 3. Complain on 9fans for a while before eventually giving up (this is
>>> the popular option)
>> 4. Keep to Linux and curse the world in wrath.
>>
>
> I forgot about #4. We almost all end up going with #4 at some point,
> to a greater or lesser extent.

Alas, fame brings drivers.

>> I'd shut up if no one _asked_ me about it, but some did.
>
> You still haven't clarified what exactly you want to do with your
> 64-bit system, besides win dicksize wars.

This is a major reason.

Me: Yeah, well, mine is 2^32 +1 units long!
Other: *Arithmetic Overflow* Curses!

> Reasons for using a 64-bit
> system include, for example, *needing* more than 4 GB of RAM. If you
> want to do stuff like Ron and Nemo have done, where you stick your
> entire filesystem in 64 GB of memory or so, then yeah it's important.
> On the other hand, I've never had a Plan 9 system with more than 4 GB
> of RAM, excepting our NIX test box, and everything has been fine--you
> don't need a lot for this OS!

Yes — the OS takes less, so the computations can have more.
Anyhow, this is not my worry — I have only 4 GB.

> Through the magic of compression, and other things like realizing that
> you don't have to redraw the *entire* screen 60 times a second when
> displaying a mostly-static desktop.
> You just send the chunks that have
> changed, *when* they change.

And when watching full-screen video, or playing full-screen 3D games?
Then it must redraw nearly the whole screen, nearly every frame.

> I'm not that familiar with how the Plan 9 graphics system works, but
> we're not talking about hardware vs software OpenGL. There is no
> OpenGL to be had here.

Not yet. It seems to be in the works:
http://plan9.bell-labs.com/wiki/plan9/todo/index.html

> This is writing bits into a framebuffer and
> having them appear on the screen. It's pretty damn fast to write
> things to main memory.

Yes, which works iff the video output is local. This I wrote in
response to the idea that I make one machine a 64-bit devoted CPU
server, which I doubt would be appropriate for my usage case and
available hardware.

Re: [9fans] AMD64 system

[John Floren]

On Wed, Apr 25, 2012 at 1:30 PM, Strake <strake888@gmail.com> wrote:
> On 25/04/2012, John Floren <john@jfloren.net> wrote:
>> There are 3 options:
>>
>> 1. Suck it up and use the 64-bit system that is available
>> 2. Write drivers for your hardware (this is the comedy option)
>> 3. Complain on 9fans for a while before eventually giving up (this is
>> the popular option)
> 4. Keep to Linux and curse the world in wrath.
>

I forgot about #4. We almost all end up going with #4 at some point,
to a greater or lesser extent.

> I'd shut up if no one _asked_ me about it, but some did.

You still haven't clarified what exactly you want to do with your
64-bit system, besides win dicksize wars. Reasons for using a 64-bit
system include, for example, *needing* more than 4 GB of RAM. If you
want to do stuff like Ron and Nemo have done, where you stick your
entire filesystem in 64 GB of memory or so, then yeah it's important.
On the other hand, I've never had a Plan 9 system with more than 4 GB
of RAM, excepting our NIX test box, and everything has been fine--you
don't need a lot for this OS!

>> I don't even know what you're attempting to imply with that
>> calculation at the end, though. What does the onboard graphics card
>> have to do with network bandwidth?
>
> It doesn't; however graphics are drawn, whether in hardware or
> software, they must be sent to terminal.
>
>> If you run a big drawterm/cpu
>> window, it won't be that high of a data rate

Through the magic of compression, and other things like realizing that
you don't have to redraw the *entire* screen 60 times a second when
displaying a mostly-static desktop. You just send the chunks that have
changed, *when* they change.

>> and it won't use the
>> graphics card anyway.
>
> Then it will be slow. Software graphics are slow.
>

I'm not that familiar with how the Plan 9 graphics system works, but
we're not talking about hardware vs software OpenGL. There is no
OpenGL to be had here. This is writing bits into a framebuffer and
having them appear on the screen. It's pretty damn fast to write
things to main memory.

john

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, John Floren <john@jfloren.net> wrote:
> There are 3 options:
>
> 1. Suck it up and use the 64-bit system that is available
> 2. Write drivers for your hardware (this is the comedy option)
> 3. Complain on 9fans for a while before eventually giving up (this is
> the popular option)
4. Keep to Linux and curse the world in wrath.

I'd shut up if no one _asked_ me about it, but some did.

> I don't even know what you're attempting to imply with that
> calculation at the end, though. What does the onboard graphics card
> have to do with network bandwidth?

It doesn't; however graphics are drawn, whether in hardware or
software, they must be sent to terminal.

> If you run a big drawterm/cpu
> window, it won't be that high of a data rate

How?

> and it won't use the
> graphics card anyway.

Then it will be slow. Software graphics are slow.

Re: [9fans] AMD64 system

[Lyndon Nerenberg]

On 2012-04-25, at 1:13 PM, Strake wrote:

> What the hell? This is a waste and a fault

Yup :-P

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, erik quanstrom <quanstro@quanstro.net> wrote:
> it's not like the registers are real on a modern x86 machine in any mode
> after renaming, etc.  and this is also offset somewhat by the fact that
> pointers are now twice as big.

It can rename them but I can't name them, so I can't keep any more
variables in the core at a time.

> also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
> and 64 bit plan 9, so recompiled programs won't get bigger integers
> just for the recompiling.

What the hell? This is a waste and a fault. long at least ought to be
at least a machine word.

Re: [9fans] AMD64 system

[Lyndon Nerenberg]

On 2012-04-25, at 1:01 PM, Strake wrote:

> The main one is this: I have a 64-bit machine, and I'll be damned if
> my programs won't use every last one of them (^_~)

Hookers?

Re: [9fans] AMD64 system

[Gorka Guardiola]

>
> The main one is this: I have a 64-bit machine, and I'll be damned if
> my programs won't use every last one of them (^_~)
>

We are going to be grateful to you saving yourself by writing
drivers...

G.

Re: [9fans] AMD64 system

[John Floren]

On Wed, Apr 25, 2012 at 12:57 PM, Strake <strake888@gmail.com> wrote:
> On 25/04/2012, John Floren <john@jfloren.net> wrote:
>> If you're doing cryptography and physical simulation, computation
>> bound stuff, why not set up a 64-bit CPU server? I've got one at work,
>> all you should need to do is get the 64-bit binaries on your
>> fileserver.
>
> Then I have a CPU server with very nice on-board sound, and powerful
> graphics card, both idle, the latter since I have no other machine
> that can take it, I have no driver, and even if I had,
> (32 b/pixel)(1920x1080 pixel)(60.0 Hz) = 4 Gb/s > network data rate = 1 Gb/s.
>

There are 3 options:

1. Suck it up and use the 64-bit system that is available
2. Write drivers for your hardware (this is the comedy option)
3. Complain on 9fans for a while before eventually giving up (this is
the popular option)

I don't even know what you're attempting to imply with that
calculation at the end, though. What does the onboard graphics card
have to do with network bandwidth? If you run a big drawterm/cpu
window, it won't be that high of a data rate, and it won't use the
graphics card anyway.

john

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> Anyway, I was just curious to see what specific real case you had for
> needing 64 bits.

The main one is this: I have a 64-bit machine, and I'll be damned if
my programs won't use every last one of them (^_~)

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, John Floren <john@jfloren.net> wrote:
> If you're doing cryptography and physical simulation, computation
> bound stuff, why not set up a 64-bit CPU server? I've got one at work,
> all you should need to do is get the 64-bit binaries on your
> fileserver.

Then I have a CPU server with very nice on-board sound, and powerful
graphics card, both idle, the latter since I have no other machine
that can take it, I have no driver, and even if I had,
(32 b/pixel)(1920x1080 pixel)(60.0 Hz) = 4 Gb/s > network data rate = 1 Gb/s.

Re: [9fans] AMD64 system

[erik quanstrom]

> Also logical memory addresses, timestamps, ...

the tsc (timestamp counter) is 64 bits regardless of processor mode.

- erik

Re: [9fans] AMD64 system

[erik quanstrom]

On Wed Apr 25 15:17:15 EDT 2012, strake888@gmail.com wrote:
> On 25/04/2012, erik quanstrom <quanstro@quanstro.net> wrote:
> > i think you mean the maximum value of an integer
> > rather than a count.  assuming this, vlongs are
> > still 64 bits with 8c and the 32-bit architecture.
> >
> > what's wrong with them?
>
> Twice as many instructions, if I'm not mistaken, and a waste of good
> 64-bit registers.

it's not like the registers are real on a modern x86 machine in any mode
after renaming, etc.  and this is also offset somewhat by the fact that
pointers are now twice as big.

so best case for 64-bit, is that you are adding 64-bit numbers in a tight
loop with almost no memory access.  i get only a 2-3x speedup for this
case

32-bit machine (not idle):
	minooka; time 8.addv
	3.08u 0.00s 3.11r 	 8.addv  # status= main
	minooka; aux/cpuid -i
	Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz

64-bit machine (idle, but slower)
	bonanza; time 6.addv
	1.55u 0.00s 1.58r 	 6.addv  # status= main
	bonanza; aux/cpuid -i
	Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz

by amdahl's law, you're going to have to be doing a hell of a lot of
vlong arithmetic to make this pay.

also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
and 64 bit plan 9, so recompiled programs won't get bigger integers
just for the recompiling.

- erik

-----
bonanza; cat addv.c
#include <u.h>
#include <libc.h>

void
main(void)
{
	int i;
	vlong acc;

	acc = 0;
	for(i = 0; i < 1000000000; i++)
		acc += i;
}

Re: [9fans] AMD64 system

[Lyndon Nerenberg]

On 2012-04-25, at 12:09 PM, Strake wrote:

> This. A limit on cryptography, physical simulation, ...
> which are computation-bound, so bignum arithmetic would be slow.
> 
> Also logical memory addresses, timestamps, ...

Don't vlongs cover this?  Perhaps the physical simulation example would like 64 bit addressing, but sparse arrays could be a viable alternative.

> Oh, and 8 registers are far too few.

Unless you're writing assembler, the compilers hide that.

Anyway, I was just curious to see what specific real case you had for needing 64 bits.  Proprietary considerations often get in the way of that.

--lyndon

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, erik quanstrom <quanstro@quanstro.net> wrote:
> i think you mean the maximum value of an integer
> rather than a count.  assuming this, vlongs are
> still 64 bits with 8c and the 32-bit architecture.
>
> what's wrong with them?

Twice as many instructions, if I'm not mistaken, and a waste of good
64-bit registers.

Re: [9fans] AMD64 system

[John Floren]

On Wed, Apr 25, 2012 at 12:09 PM, Strake <strake888@gmail.com> wrote:
> On 25/04/2012, Matthew Veety <mveety@gmail.com> wrote:
>> On Apr 25, 2012 2:27 PM, "Lyndon Nerenberg" <lyndon@orthanc.ca> wrote:
>>> On 2012-04-25, at 11:04 AM, Strake wrote:
>>> > Four billion is not enough.
>>>
>>> Not enough what?  This cat's curiosity is raised.
>>>
>>
>> Numbers obviously.
>
> This. A limit on cryptography, physical simulation, ...
> which are computation-bound, so bignum arithmetic would be slow.
>
> Also logical memory addresses, timestamps, ...
>
> Oh, and 8 registers are far too few.
>

If you're doing cryptography and physical simulation, computation
bound stuff, why not set up a 64-bit CPU server? I've got one at work,
all you should need to do is get the 64-bit binaries on your
fileserver.

John

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, Matthew Veety <mveety@gmail.com> wrote:
> On Apr 25, 2012 2:27 PM, "Lyndon Nerenberg" <lyndon@orthanc.ca> wrote:
>> On 2012-04-25, at 11:04 AM, Strake wrote:
>> > Four billion is not enough.
>>
>> Not enough what?  This cat's curiosity is raised.
>>
>
> Numbers obviously.

This. A limit on cryptography, physical simulation, ...
which are computation-bound, so bignum arithmetic would be slow.

Also logical memory addresses, timestamps, ...

Oh, and 8 registers are far too few.

Re: [9fans] AMD64 system

[erik quanstrom]

> > On 2012-04-25, at 11:04 AM, Strake wrote:
> >
> > > Four billion is not enough.
> >
> > Not enough what?  This cat's curiosity is raised.
> >
>
> Numbers obviously.

i think you mean the maximum value of an integer
rather than a count.  assuming this, vlongs are
still 64 bits with 8c and the 32-bit architecture.

what's wrong with them?

- erik

Re: [9fans] AMD64 system

[Matthew Veety]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On Apr 25, 2012 2:27 PM, "Lyndon Nerenberg" <lyndon@orthanc.ca> wrote:
>
>
> On 2012-04-25, at 11:04 AM, Strake wrote:
>
> > Four billion is not enough.
>
> Not enough what?  This cat's curiosity is raised.
>

Numbers obviously.

--
Veety

[-- Attachment #2: Type: text/html, Size: 398 bytes --]

Re: [9fans] AMD64 system

[Lyndon Nerenberg]

On 2012-04-25, at 11:04 AM, Strake wrote:

> Four billion is not enough.

Not enough what?  This cat's curiosity is raised.

Re: [9fans] AMD64 system

[erik quanstrom]

> On 25/04/2012, erik quanstrom <quanstro@quanstro.net> wrote:
> >> I just lately installed Plan 9, but the stock system is built for
> >> 32-bit x86, and I have an amd64 computer.
> >
> > the stock system will work find for you.
>
> Assume s/find/fine/.
>
> 32-bit is not fine.
>
> Four billion is not enough.

can you be more specific?  what do you need exactly?

- erik

Re: [9fans] AMD64 system

[Strake]

On 25/04/2012, erik quanstrom <quanstro@quanstro.net> wrote:
>> I just lately installed Plan 9, but the stock system is built for
>> 32-bit x86, and I have an amd64 computer.
>
> the stock system will work find for you.

Assume s/find/fine/.

32-bit is not fine.

Four billion is not enough.

>> I found this diff: http://9legacy.org/9legacy/patch/nix.diff
>> which seems to have all needed system libraries, and its own kernel,
>> but the kernel seems to lack basic functionality, such as graphics and
>> mouse, and I can't find the local bootloader for it — the stock
>
> unfortunately, it can't be run easily on a terminal yet due to the lack
> of graphics, as you note.
>
> /n/sources/contrib/quanstro/root/sys/src/boot/pc-e820 will boot amd64
> and pc kernels.

Ah, thanks.

> the fact that the amd64 port is immature doesn't mean that the
> system isn't portable.  it may mean that x86 is a complicated place
> to work.  :-)

The majority charge carrier in an x86 chip is the moron, not the electron.
I mean to get a Loongson system, when one such is available and not
memory-crippled. I'd just have to port Plan 9 again, to MIPS...

Cheers,
strake

Re: [9fans] AMD64 system

[erik quanstrom]

> I just lately installed Plan 9, but the stock system is built for
> 32-bit x86, and I have an amd64 computer.

the stock system will work find for you.

> I found this diff: http://9legacy.org/9legacy/patch/nix.diff
> which seems to have all needed system libraries, and its own kernel,
> but the kernel seems to lack basic functionality, such as graphics and
> mouse, and I can't find the local bootloader for it — the stock

unfortunately, it can't be run easily on a terminal yet due to the lack
of graphics, as you note.

/n/sources/contrib/quanstro/root/sys/src/boot/pc-e820 will boot amd64
and pc kernels.

the source is at
	http://code.google.com/p/nix-os  (hopefully correctly typed)
and
	/n/sources.lsub.org/nix

the official bootloader is at

	/n/sources.lsub.org/nix/sys/src/nix/w/pxeload

> I feel a bit lost. In the documentation, the authours emphasize its
> portability, yet to actually build for another architecture seems
> quite a bother, regrettably, since I was quite enthusiastic to use it
> as my primary system.

the fact that the amd64 port is immature doesn't mean that the
system isn't portable.  it may mean that x86 is a complicated place
to work.  :-)

- erik