[9fans] a problem I don't understand on a reinstall

[9fans] a problem I don't understand on a reinstall

[ron minnich]

I had a T21, with partitions:
9fat
fs
swap

I booted the install cd, and using prepdisk I delete swap and fs, then
added
fossil
arenas0
arenas1
isect0
isect1
swap

Then I installed. Once done, it would not boot. Plan9.ini was rewritten by
the install, but set up with the local file system as local!#S/sdC0/fs,
not local!#S/sdC0/fossil.

Booted CD, ran 9fat:, changed it to fossil, instead of fs, it still
wouldn't boot. 9load complains that it can't find any partitions other
than 9fat.

reinstalled. No good. On the reinstall the 9fat was not updated, so still
had the identical plan9.ini.

Reinstalled, but this time using prep I deleted all partitions, including
9fat, then added them back, resizing them for good measure.

Still failed to boot, it's still trying to find 'fs', not 'fossil'.

ARG!

Found on booting cdrom to look around that 9fat, though resized, was
unchanged: plan9.ini was the same as before the delete all partitions,
reallocate all partitions step.

Well, what's going on here? how do I get this cd to wipe everything down
to completely clean state when it installs? Should I run fdisk/mbr from
the boot cd, then try it? It's as though too much state is being saved in
the boot info somewhere, across installs. Is it not setting up 9load
correctly? Is it not replacing 9load with a new one?

ron

Re: [9fans] a problem I don't understand on a reinstall

[Russ Cox]

> Well, what's going on here? how do I get this cd to wipe everything down
> to completely clean state when it installs? Should I run fdisk/mbr from
> the boot cd, then try it? It's as though too much state is being saved in
> the boot info somewhere, across installs. Is it not setting up 9load
> correctly? Is it not replacing 9load with a new one?

first, use the bleeding-edge cd-rom,
just in case it has a fix that you need.
(but i doubt it does).

when you get into the install at the beginning,
draw a new window and

	cp /dev/zero /dev/sdC0/data

and then wait a few seconds and hit delete.
that should clear things pretty good.

russ

Re: [9fans] My Eu paper, mark 2

[John DeGood]

Geoff Collyer <geoff@collyer.net> wrote:

> And MIPS's compilers are elephantine, so it's likely that
> they had armies working on them.

Below is a response from Steve Correll <sjc@pobox.com>,
a member of the original MIPS compiler team.

John

 > You're welcome to attribute this to me if you want to post a followup.
 >
 > Today's MIPS compilers may be the product of an army, but for version
 > 1.0 there was just a platoon (benefiting, of course, from the AT&T
 > compiler front ends, Berkeley dbx, and various Stanford research
 > projects):
 >
 > Fred Chow - optimizer
 > Steve Correll - assembler, prof
 > Kevin Enderby - ld
 > Steve Hanson - f77, cc
 > Mark Himelstein - dbx
 > John Ho - codegen
 > Earl Killian - codegen, pixie
 > Larry Weber - assembler

Re: [9fans] a problem I don't understand on a reinstall

[ron minnich]

On Thu, 16 Oct 2003, Russ Cox wrote:

> first, use the bleeding-edge cd-rom,
> just in case it has a fix that you need.
> (but i doubt it does).

No, I was using that CDROM and still saw the 'historical partitions'.


> when you get into the install at the beginning,
> draw a new window and
>
> 	cp /dev/zero /dev/sdC0/data

That did it. There's nothing like splating the disk with zeros to clean up
things. Nice, clean oxide oersteds.

ron

[9fans] My Eu paper, mark 2

[Laura Creighton]

I have to answer the question 'how do you know you have enough
people on the project'?  I just want to write a compiler, and
after all, the syntax of the language is fixed.  I want to say
we don't want a bloody army, after all C was made by X people,
Y helping and C++ by Q people, R people helping.

Anybody here know what X Y Q R are?

Laura

Re: [9fans] My Eu paper, mark 2

[Geoff Collyer]

I believe dmr wrote the original C compiler by himself, without yacc.
pcc was written by Steve Johnson, with yacc, and I think he did it by
himself.  The plan 9 C compilers were written by Ken Thompson, with
yacc.  Ken claims that it takes 3 weeks to port his compiler (and
assembler and loader) to a new machine, but that's with Ken doing the
porting, working long days.  There are at least the 13 ports that I
know of.  Charles Forsyth did the power pc port (qc).  If LANL comes
through with money, I may end up porting it to the AMD K8.  lcc was
written by Dave Hanson and Chris Fraser; Norman Wilson has ported it
to the VAX.

I'm less sure about C++.  I think it was, at least initially, done by
Bjarne, with yacc.

Limbo was implemented by Sean Dorward, with yacc, I think unassisted.

f77 was written by Stu Feldman, with yacc, and with Peter Weinberger
contributing the Fortran libraries (e.g., for I/O).

There are undoubtedly compilers that I'm less familiar with that were
implemented by an army (probably IBM's compilers, at least in the old
days), but that was probably due to the habit of throwing armies at
problems rather than any real need.  I don't know how many people were
used to implement the full Algol 68 language either.  And MIPS's
compilers are elephantine, so it's likely that they had armies working
on them.

Re: [9fans] My Eu paper, mark 2

[Charles Forsyth]

>>yacc.  Ken claims that it takes 3 weeks to port his compiler (and
>>assembler and loader) to a new machine, but that's with Ken doing the
>>porting, working long days.

it can be somewhat less than that.  it rather depends
on the nature of the target processor, whether there's something
similar in the existing suite, and whether you feel the need to do an
interpreter as well.  i've found it the easiest
compiler suite to port that produces reasonable code.
i like its broad division of work for the machine analysis.
unlike the usual assembler/linker grunge, to which people seem glued,
there isn't repetition of work as regards the instruction encoding.
lcc is probably quicker to port but then you still need the
usual assembler/loader grunge, and the code isn't as good.
(nice compiler, though.)

>>problems rather than any real need.  I don't know how many people were
>>used to implement the full Algol 68 language either.  And MIPS's

Algol68R and Algol68C were both done by comparatively small groups,
although it would probably be fair to say that both compilers did subsets.

Re: [9fans] My Eu paper, mark 2

[Geoff Collyer]

I know that there was at least one implementation of the full Algol 68
language.  It was for the IBM 370 series, called FLACC (Full-Language
Algol-68 Check-out Compiler).  UBC had it, years ago.  No idea how
many people it took to do it, though.

Re: [9fans] My Eu paper, mark 2

[Lyndon Nerenberg]

On Saturday, October 11, 2003 2:27 AM -0700 Geoff Collyer
<geoff@collyer.net> wrote:

> I know that there was at least one implementation of the full Algol 68
> language.  It was for the IBM 370 series, called FLACC (Full-Language
> Algol-68 Check-out Compiler).  UBC had it, years ago.  No idea how
> many people it took to do it, though.

As I recall, Chris Thompson from the U of Alberta was either the
principal architect or lead programmer (or both) of this project, and the
environment was MTS running on the UofA's Amdahl 470. All circa 1982.

I have a minimal set of doc for this compiler sitting in a box buried
somewhere in the garage ...

--lyndon

Re: [9fans] My Eu paper, mark 2

[Geoff Collyer]

Sorry, that was meant to be private mail to Laura.

Re: [9fans] My Eu paper, mark 2

[Douglas A. Gwyn]

Laura Creighton wrote:
> ... C was made by X people,
> Y helping and C++ by Q people, R people helping.
> Anybody here know what X Y Q R are?

Actually small armies did become involved.
The original versions of C and C++ were designed
by single individuals, and implemented by the
same (although C++ required a C implementation);
there is a lot of support structure (linkers,
libraries, debuggers, etc.) that dragged in other
contributors.  For example Mike Lesk worked on
the early version of a portable I/O library and
Steve Johnson worked on the Portable C Compiler.
By the time C was "commercial" there were several
people working on it and its surrounding software
generation system.  And of course the languages
kept growing, with contributions one way or
another by hundreds.

I think you could reasonably say that a general-
purpose programming language can be designed and
implemented in a limited context by one person
(there are other historical examples), but it
takes significantly more resources to turn it
into an industrial-strength product.