Re: [9fans] too good to pass up (SRB Comments)

Re: [9fans] too good to pass up (SRB Comments)

[erik quanstrom]

it was not cleaned up in the xinu bsd source.  iirc, on a vax,
it would coredump fairly reliably.  i spent some time trying
to figure out what the malfunction was, but never could.

i blamed nfs, since it was the convient thing to do, and
started using byron's rc.

the coding style was never a significant problem.  if it were,
i could have easily written a script to replace the odd #defines.

- erik

On Fri Apr 28 08:12:19 CDT 2006, brantley@coraid.com wrote:
> That was really John Mashy's fault, as I understand it.  He suggested
> it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
> bad every processor wasn't as clean in this reguard as the PDP-11.
>
> For those who might not have heard of this, SRB caught segfault
> signals, allocated more memory and just returned.  The instruction
> that caused the segfault would restart.  It was an automatic memory
> allocator.  Problem was that not all processors could pull off this
> sort of stunt.
>
> Geoff cleaned this up years ago.
>
> > not even his allocator?
> >
> > - erik
> >
> > On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
> >> > Not that I'm defending writing C as
> >> > though it were Algol 68...
> >>
> >> I kind of liked it after the initial shock.
> >> Even inspired the Obfuscated C Contest.
> >> I don't think SRB's code was obfuscated, though.
> >>
> >>
>
>

Re: [9fans] too good to pass up (SRB Comments)

[quanstro]

i read this several weeks ago.  thanks for taking the time to document this.
i found it very instructive.

- erik

On Fri Apr 28 16:14:49 CDT 2006, geoff@collyer.net wrote:
> The cleanup I did was relatively late in the game (1988) and was done
> to the Ninth Edition Unix sh.  My stak.c is available at my web page
> (www.collyer.net/who/geoff) but the fixes didn't get back into most
> shells (Cray may have picked them up).
>
> As I noted in the corresponding paper, A Partial Tour Through the UNIX
> Shell,
>
> 	The shell was the last program ported to the Interdata during
> 	the original UNIX port, due to the difficulty of getting the
> 	details of restarting faulting instructions just right, which
> 	is why the Seventh Edition (also known as ``V7'') distribution
> 	tape includes /bin/osh, the Sixth Edition shell.
>
>

Re: [9fans] too good to pass up (SRB Comments)

[geoff]

The cleanup I did was relatively late in the game (1988) and was done
to the Ninth Edition Unix sh.  My stak.c is available at my web page
(www.collyer.net/who/geoff) but the fixes didn't get back into most
shells (Cray may have picked them up).

As I noted in the corresponding paper, A Partial Tour Through the UNIX
Shell,

	The shell was the last program ported to the Interdata during
	the original UNIX port, due to the difficulty of getting the
	details of restarting faulting instructions just right, which
	is why the Seventh Edition (also known as ``V7'') distribution
	tape includes /bin/osh, the Sixth Edition shell.

Re: [9fans] too good to pass up (SRB Comments)

[Richard Miller]

geoff@collyer.net said:

> 	The shell was the last program ported to the Interdata during
> 	the original UNIX port, due to the difficulty of getting the
> 	details of restarting faulting instructions just right, which
> 	is why the Seventh Edition (also known as ``V7'') distribution
> 	tape includes /bin/osh, the Sixth Edition shell.

The Wollongong University version of the Bourne shell on the Interdata
contains this comment:

	/***
	 *** Don't rely on hardware to recover from address errors!
	 ***/

I took the easy way out and rewrote the allocator to make sure it
extended the address space before the memory was used, rather than
relying on recoverable address faults.  Much more portable.

-- Richard

Re: [9fans] too good to pass up (SRB Comments)

[geoff]

Allocating the space before use would be straightforward for Bourne's
`heap' storage (the blok.c allocator).  Did you modify all the `stak'
macros and functions also to increase the break as needed?

There were other advantages to using the C library's malloc, notably
being able to call arbitrary C library functions, such as the
directory-reading routines, even if they used malloc.

Re: [9fans] too good to pass up (SRB Comments)

[Richard Miller]

> Did you modify all the `stak'
> macros and functions also to increase the break as needed?

I must have done.

On the other hand, the C stack (for all programs, not just sh)
had a fixed size determined at ld time, because I decided to
have the stack grow downwards as it did on the pdp11, even though
the interdata could only extend memory segments upwards.  I was
worried that all sorts of things might break if the stack went
the other way, but in hindsight this was probably the biggest
mistake I made in that project.

Re: [9fans] too good to pass up (SRB Comments)

[Roman Shaposhnik]

On Fri, 2006-04-28 at 09:10 -0400, Brantley Coile wrote:
> That was really John Mashy's fault, as I understand it.  He suggested
> it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
> bad every processor wasn't as clean in this reguard as the PDP-11.
> 
> For those who might not have heard of this, SRB caught segfault
> signals, allocated more memory and just returned.  The instruction
> that caused the segfault would restart.  It was an automatic memory
> allocator.  Problem was that not all processors could pull off this
> sort of stunt.

  That's some tricky programming! Do you know of any place one can get
an access to the original code ?

Thanks,
Roman.

Re: [9fans] too good to pass up (SRB Comments)

[Taj Khattra]

>   That's some tricky programming! Do you know of any place one can get
> an access to the original code ?

you can browse it here:
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/fault.c.html

Re: [9fans] too good to pass up (SRB Comments)

[Brantley Coile]

That was really John Mashy's fault, as I understand it.  He suggested
it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
bad every processor wasn't as clean in this reguard as the PDP-11.

For those who might not have heard of this, SRB caught segfault
signals, allocated more memory and just returned.  The instruction
that caused the segfault would restart.  It was an automatic memory
allocator.  Problem was that not all processors could pull off this
sort of stunt.

Geoff cleaned this up years ago.

> not even his allocator?
>
> - erik
>
> On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
>> > Not that I'm defending writing C as
>> > though it were Algol 68...
>>
>> I kind of liked it after the initial shock.
>> Even inspired the Obfuscated C Contest.
>> I don't think SRB's code was obfuscated, though.
>>
>>