Re: [9fans] Ultrasparc II

Re: [9fans] Ultrasparc II

[Geoff Collyer]

Is there any need for a separate sparc v9 compiler?  I thought v9
sparcs ran v8 programs.

Re: [9fans] Ultrasparc II

[Peter Downs]

> Is there any need for a separate sparc v9 compiler?  I thought v9
> sparcs ran v8 programs.

Only if there is no distinct difference between need and `hopes
and desires'

v9 does run v8 code, but v8 is 32-bit where v9 is 64.

My understanding is that plan 9 doesn't run on newer suns because
the needed drivers aren't there for newer devices, including the
sparc v9 mmu.  But a 64-bit implementation would be nice.
Am I wrong in thinking plan 9 would run well on 64-bit sparc v9, or
have I missed something?

peter

Re: [9fans] Ultrasparc II

[rob pike, esq.]

To put it bluntly,  Plan 9 is not a 64-bit system.  In particular,
the kernel is strongly a 32-bit environment, not that we're proud
of that fact.  Changing the system to use 64 bit pointers would
require some major changes to break various symmetries that were,
for better or worse, thought reasonable when the system was first
written, such as value equivalence of pointers and integers.

-rob

Re: [9fans] Ultrasparc II

[Geoff Collyer]

> k[al] *do* generate instructions not present in sparc v9, notably
> RETT, as well as read and writes to the trap base register and other
> registers which no longer exist, etc.

Right, and different kernel code written in assembler would have to be
executed for v8 (and earlier) sparcs and v9 (and later) sparcs.  It's
more of an issue for assembler programmers than for the k[cal] suite.
In the second edition sparc port(s), for example, there were all of 3
RETTs in each of the ss and ss10 implementations (out of 520 and 564
lines of assember in total, respectively):

: cpu; grep -i rett */*.s
ss/l.s:	SAVE	R0, R0			/* RETT is implicit RESTORE */
ss/l.s:	RETT	R7, R8
ss/l.s:	RETT	R17, R18
ss/l.s:	RETT	R17, R18
ss10/l.s:	SAVE	R0, R0			/* RETT is implicit RESTORE */
ss10/l.s:	RETT	R7, R8
ss10/l.s:	RETT	R17, R18
ss10/l.s:	RETT	R17, R18

> [...] I thought it might be simpler to branch off a new
> compiler-assembler-linker group, rather than pepper the source "#ifdef
> sparcv9 " directives.

You definitely shouldn't add ifdefs (to anything)!  See
/sys/doc/^(9.ps comp.ps) for why.  A few tests (at run-time or
compile-time) can tell you whether to run v8 or v9 kernel assembler
fragments, where the difference matters (e.g., trap handlers).  I
believe that changes to k[cal] to make pointers 64 bits could be small
and isolated (not that it's necessarily worth doing, as rob observed).
In terms of code generated, I think it's mostly a matter of generating
8-byte loads and stores of pointers rather than 4-byte ones.  v9 has
widened the processor registers to 64 bits already.

Re: [9fans] Ultrasparc II

[John Packer]

> As for different trap models, etc. in sparcs, it looks to me like all
> of that stuff is only visible in kernel mode, and the compilers don't
> generate the relevant instructions *now*, let alone for v9.  So adding
> the v9 instructions by hand to assembler source files or augmenting ka
> and kl should do the job; I don't think kc is involved.  Mixing old
> and new instructions is expected; that's the whole point of v9's
> compatibility with older sparc versions.  See the v9 spec. for the
> full story.
>
> The situation was different with 2c vs 1c (68020+ vs 68000): 2c was
> the older compiler and generated instructions and addressing modes not
> present in the 68000.

Sorry, I'm wasn't trying to complicate things.

By "compiler," I was referring the group kc, ka, and kl.

What I meant was, k[al] *do* generate instructions not
present in sparc v9, notably RETT, as well as read and writes
to the trap base register and other registers which no longer
exist, etc.

Maybe that is not such a big issue, but coupled with the
pointer handling, the changes in privileged registers, and
all the consequent changes to libmach, I thought it might be
simpler to branch off a new compiler-assembler-linker group,
rather than pepper the source "#ifdef sparcv9 " directives.

Re: [9fans] Ultrasparc II

[John Packer]

> As for different trap models, etc. in sparcs, it looks to me like all
> of that stuff is only visible in kernel mode, and the compilers don't
> generate the relevant instructions *now*, let alone for v9.  So adding
> the v9 instructions by hand to assembler source files or augmenting ka
> and kl should do the job; I don't think kc is involved.  Mixing old
> and new instructions is expected; that's the whole point of v9's
> compatibility with older sparc versions.  See the v9 spec. for the
> full story.
>
> The situation was different with 2c vs 1c (68020+ vs 68000): 2c was
> the older compiler and generated instructions and addressing modes not
> present in the 68000.

Sorry, I'm wasn't trying to complicate things.

By "compiler," I was referring the group kc, ka, and kl.

What I meant was, k[al] *do* generate instructions not
present in sparc v9, notably RETT, as well as read and writes
to the trap base register and other registers which no longer
exist, etc.

Maybe that is not such a big issue, but coupled with the
pointer handling, the changes in privileged registers, and
all the consequent changes to libmach, I thought it might be
simpler to branch off a new compiler-assembler-linker group,
rather than pepper the source "#ifdef sparcv9 " directives.

Re: [9fans] Ultrasparc II

[Geoff Collyer]

By `here', I meant 9fans.  Scott Schwartz's gang at PSU would like
more address space, presumably for gene mapping or related work.

As for different trap models, etc. in sparcs, it looks to me like all
of that stuff is only visible in kernel mode, and the compilers don't
generate the relevant instructions *now*, let alone for v9.  So adding
the v9 instructions by hand to assembler source files or augmenting ka
and kl should do the job; I don't think kc is involved.  Mixing old
and new instructions is expected; that's the whole point of v9's
compatibility with older sparc versions.  See the v9 spec. for the
full story.

The situation was different with 2c vs 1c (68020+ vs 68000): 2c was
the older compiler and generated instructions and addressing modes not
present in the 68000.  The Various Ports says of the 68000 compiler
``It generates position-independent code whose overall quality is much
poorer than the code for the MC68020.'' and the code differences are
not trivial:

: cpu; diff -rw [12]c|wc -l
    517
: cpu; diff -rw [12]a|wc -l
    199
: cpu; diff -rw [12]l|wc -l
    940

Re: [9fans] Ultrasparc II

[Charles Forsyth]

>>Otherwise the new instructions could be accessed by using WORD
>>macros in assembler, and not changing the ka and kl at all.

i often did that with the powerpc because the system interface
changed somewhat between devices and there were plenty of
instructions in q[acl] as it stood, thanks to the architecture.
since only a few files in the kernel (eg, l.s) needed to access
the system instructions and control registers directly it
was easier to define a few special things there.

Re: [9fans] Ultrasparc II

[rob pike, esq.]

> Adding the instructions to ka and kl is easy, but isn't it cleaner to spin
> off a new compiler, as was done between the 68020-68040
> compilers, rather than adding a lot of new options?

Actually these two architectures are both supported by 2c etc.; we
didn't spin a new compiler.  We *did* spin one for the MIPS 4K, and
some attempt was made to exploit the 64-bit registers, but no 64-bit
kernel was ever attempted; it was an abortive attempt.

-rob

Re: [9fans] Ultrasparc II

[John Packer]

Besides the issue of pointer sizes, the control registers have changed:
the PSR, TBR, and WIM registers don't exist, and have been replaced
by a dozen other registers. The trap model is completely different, and
the instruction set has changed (to use the new registers), etc..

Adding the instructions to ka and kl is easy, but isn't it cleaner to spin
off a new compiler, as was done between the 68020-68040
compilers, rather than adding a lot of new options? What happens if
you mix instructions for the old registers and instructions for the new?

Otherwise the new instructions could be accessed by using WORD
macros in assembler, and not changing the ka and kl at all.

> If one were to make a v9 sparc port use 64-bit addressing, I think the
> existing compiler or loader would just need an option to generate the
> new v9 instructions for 64-bit operands; I can't see the point of a
> distinct v9 compiler.  But a quick glance at the differences between
> sparc v8 and v9 suggests that the real fun would be in the kernel
> anyway.

Re: [9fans] Ultrasparc II

[Jack Johnson]

Geoff Collyer wrote:
> So far the Plan 9 compilers implement a 64-bit long long type but
> nobody has yet tried making pointers 64 bits.  Even the alpha port
> uses 32-bit addressing.  Nobody here but the biologists has yet been
> complaining about feeling squeezed in a 32-bit address space.

Are your biologists doing bioinformatics work with Plan 9?

That must be interesting to say the least.  When do we get to see the
statistical analysis of their GenBank Venti archive?  ;)

-Jack

(Seriously, it does sound like fun.)

Re: [9fans] Ultrasparc II

[Peter Downs]

> So far the Plan 9 compilers implement a 64-bit long long type but
> nobody has yet tried making pointers 64 bits.  Even the alpha port

Duely noted.  I was going to ask about that, since the tlb miss handler
might need them.

> If one were to make a v9 sparc port use 64-bit addressing, I think the
> existing compiler or loader would just need an option to generate the
> new v9 instructions for 64-bit operands; I can't see the point of a
> distinct v9 compiler.  But a quick glance at the differences between
> sparc v8 and v9 suggests that the real fun would be in the kernel
> anyway.

hmm.  I ordered a copy of the sparc architecture manual, version 9.
Meanwhile, maybe I should look at the compiler/linker source code.

peter

Re: [9fans] Ultrasparc II

[Charles Forsyth]

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

initially i'd be inclined to keep the amount of 64-bit code to
a minimum, by running the processor in 32-bit mode, as i
as i believe was done on the alpha.
that way you get something reasonably pleasant sooner.

[-- Attachment #2: Type: message/rfc822, Size: 1432 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ultrasparc II
Date: Tue, 17 Sep 2002 21:59:53 -0700
Message-ID: <eef2d9b4ad2aa870df9b2d8b3b9fab4b@collyer.net>

Is there any need for a separate sparc v9 compiler?  I thought v9
sparcs ran v8 programs.

Re: [9fans] Ultrasparc II

[Geoff Collyer]

So far the Plan 9 compilers implement a 64-bit long long type but
nobody has yet tried making pointers 64 bits.  Even the alpha port
uses 32-bit addressing.  Nobody here but the biologists has yet been
complaining about feeling squeezed in a 32-bit address space.

If one were to make a v9 sparc port use 64-bit addressing, I think the
existing compiler or loader would just need an option to generate the
new v9 instructions for 64-bit operands; I can't see the point of a
distinct v9 compiler.  But a quick glance at the differences between
sparc v8 and v9 suggests that the real fun would be in the kernel
anyway.

[9fans] Ultrasparc II

[Peter Downs]

I've located the Ultrasparc II User's Guide, which has a nice
28 page section on MMU internals.  Some of the mechanisms are pretty
similar to sparcv8.

Has anyone out there worked on a sparcv9 compiler?

-- for those who care about sparc64 plan 9

peter