9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Ultrasparc II
@ 2002-09-18  4:59 Geoff Collyer
  2002-09-18  6:40 ` Peter Downs
  0 siblings, 1 reply; 15+ messages in thread
From: Geoff Collyer @ 2002-09-18  4:59 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18  4:59 [9fans] Ultrasparc II Geoff Collyer
@ 2002-09-18  6:40 ` Peter Downs
  2002-09-18 16:48   ` rob pike, esq.
  0 siblings, 1 reply; 15+ messages in thread
From: Peter Downs @ 2002-09-18  6:40 UTC (permalink / raw)
  To: 9fans

> 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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18  6:40 ` Peter Downs
@ 2002-09-18 16:48   ` rob pike, esq.
  0 siblings, 0 replies; 15+ messages in thread
From: rob pike, esq. @ 2002-09-18 16:48 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-19  2:10 Geoff Collyer
  0 siblings, 0 replies; 15+ messages in thread
From: Geoff Collyer @ 2002-09-19  2:10 UTC (permalink / raw)
  To: 9fans

> 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18 23:45 Geoff Collyer
  2002-09-19  1:07 ` John Packer
@ 2002-09-19  1:09 ` John Packer
  1 sibling, 0 replies; 15+ messages in thread
From: John Packer @ 2002-09-19  1:09 UTC (permalink / raw)
  To: 9fans

> 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18 23:45 Geoff Collyer
@ 2002-09-19  1:07 ` John Packer
  2002-09-19  1:09 ` John Packer
  1 sibling, 0 replies; 15+ messages in thread
From: John Packer @ 2002-09-19  1:07 UTC (permalink / raw)
  To: 9fans

> 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-18 23:45 Geoff Collyer
  2002-09-19  1:07 ` John Packer
  2002-09-19  1:09 ` John Packer
  0 siblings, 2 replies; 15+ messages in thread
From: Geoff Collyer @ 2002-09-18 23:45 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-18 19:10 Charles Forsyth
  0 siblings, 0 replies; 15+ messages in thread
From: Charles Forsyth @ 2002-09-18 19:10 UTC (permalink / raw)
  To: 9fans

>>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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-18 18:21 rob pike, esq.
  0 siblings, 0 replies; 15+ messages in thread
From: rob pike, esq. @ 2002-09-18 18:21 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18  6:49 Geoff Collyer
  2002-09-18  7:37 ` Peter Downs
  2002-09-18 15:06 ` Jack Johnson
@ 2002-09-18 15:50 ` John Packer
  2 siblings, 0 replies; 15+ messages in thread
From: John Packer @ 2002-09-18 15:50 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18  6:49 Geoff Collyer
  2002-09-18  7:37 ` Peter Downs
@ 2002-09-18 15:06 ` Jack Johnson
  2002-09-18 15:50 ` John Packer
  2 siblings, 0 replies; 15+ messages in thread
From: Jack Johnson @ 2002-09-18 15:06 UTC (permalink / raw)
  To: 9fans

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.)



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
  2002-09-18  6:49 Geoff Collyer
@ 2002-09-18  7:37 ` Peter Downs
  2002-09-18 15:06 ` Jack Johnson
  2002-09-18 15:50 ` John Packer
  2 siblings, 0 replies; 15+ messages in thread
From: Peter Downs @ 2002-09-18  7:37 UTC (permalink / raw)
  To: 9fans

> 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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-18  7:05 Charles Forsyth
  0 siblings, 0 replies; 15+ messages in thread
From: Charles Forsyth @ 2002-09-18  7:05 UTC (permalink / raw)
  To: 9fans

[-- 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] Ultrasparc II
@ 2002-09-18  6:49 Geoff Collyer
  2002-09-18  7:37 ` Peter Downs
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Geoff Collyer @ 2002-09-18  6:49 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [9fans] Ultrasparc II
  2002-09-18  2:56 [9fans] multiprocessor Andrew
@ 2002-09-18  4:43 ` Peter Downs
  0 siblings, 0 replies; 15+ messages in thread
From: Peter Downs @ 2002-09-18  4:43 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2002-09-19  2:10 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-18  4:59 [9fans] Ultrasparc II Geoff Collyer
2002-09-18  6:40 ` Peter Downs
2002-09-18 16:48   ` rob pike, esq.
  -- strict thread matches above, loose matches on Subject: below --
2002-09-19  2:10 Geoff Collyer
2002-09-18 23:45 Geoff Collyer
2002-09-19  1:07 ` John Packer
2002-09-19  1:09 ` John Packer
2002-09-18 19:10 Charles Forsyth
2002-09-18 18:21 rob pike, esq.
2002-09-18  7:05 Charles Forsyth
2002-09-18  6:49 Geoff Collyer
2002-09-18  7:37 ` Peter Downs
2002-09-18 15:06 ` Jack Johnson
2002-09-18 15:50 ` John Packer
2002-09-18  2:56 [9fans] multiprocessor Andrew
2002-09-18  4:43 ` [9fans] Ultrasparc II Peter Downs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).