[comp.unix.wizards] Joy of Joys

stuart@hcr.UUCP (Stuart Thompson) (06/27/88)

The C-shell has some VAX machine dependent code which makes some very basic
assumptions about the address space of the VAX machine to control memory
allocation/dealloction.  Due to the way the C-shell mixes pointers to data
from both the data segment (static data) and the break area (dynamic data),
a special function called xfree() is used to determine which data area on
the stack a pointer refers to before memory is deallocated (using free()).

In the figure below, the data segment, which includes both the "bss" and
"data" areas of the stack has a lower address space than that of the break
area (shown as "sbrk area" the figure).  The xfree() function does the
following:

xfree(cp)
char *cp;
{
	extern int end;	/* end of data segment */

	if (cp >= end && cp < (char *)&cp)
		free();
}

The if statement in xfree() checks that:
	1) cp points above the data segment, i.e. not in the data segment
	2) the address for the actual data for cp is below the current
	   stack frame, i.e. is not local in the current stack frame

           VAX  STACK
hi addr _________________
        |               |
        |               | <- pointer to data (&cp)
        |===============| current stack frame
        |               |
        |---------------|
        |               |
        |     sbrk      |
        |     area      |
        |               | <- address of data (cp)
        |               |
        |---------------| (end)
        |     bss       |
        |---------------|
        |     data      |
lo addr -----------------


It should be noted that the if statement in xfree() will only work on machines
with a stack structure similar to that of the VAX.  The onlyread() function
in the C-shell also contains the same sort of machine dependent assumptions.

For many other machine architectures whose address space does not correspond
to that of a VAX, porting the C-shell requires making interesting workarounds.
One such implementation is in the VX/VE UNIX emulation on CDC CYBER machines.
Segments on CYBERs are quite different than on a VAX, the break area resides
in an extensible segment which has no fixed relation to either the stack segment
or data segments.  In this case, we must modify xfree() and onlyread() to
compare segment numbers between pointers rather than relative stack addresses.

A truly portable C-shell should use non-machine dependent mechanisms to
distinguish between pointers to dynamic data and pointers to static data.

_____
Stuart E. Thompson
Just another techie
{utzoo,utcsri}!hcr!stuart

boyd@basser.oz (Boyd Roberts) (07/08/88)

Those coders who believe all the world is a VAX are just
wrong-wrong-wrong.  There's a machine in the UK called an
Orion made by some people called High Level Hardware.  It
has TWO (count them) stacks and is word (32 bit) addressed.
Miss-aligned byte references don't fault and the byte offset
is in the HIGH order address bits.  So you get a byte address
space that looks something like this:

	0x00000000
	0x10000000
	0x20000000
	0x30000000
	0x00000001
	0x10000001
	0x20000001
	0x30000001

	    etc...

But then the two stacks come in.  A high order bit (in fact two)
select which stack you're referencing.  Either, the ``scalar''
or the ``vector'' stack.  The address space is NOT contiguous.

Stick to K&R and you're fine.

Somehow High Level Hardware ported 4.2BSD to their box.  They
must have been crazy!!  I used it & it worked.  Hats off to
HLH, but their hardware people should've been shot.  Worse
still I think I heard rumours about them releasing NFS on it.

Now if XDR ain't VAX dependant, I don't know what is.  SysV NFS 2.0
XDR has some real cuties for non VAX byte order machines.  Puke!
One Sunday afternoon & a lot of printf's later I found it.  Assuming
how unions/structures are packed & passed to function calls as their
constituent elements is NO way to write a ``portable'' piece of code.


Boyd Roberts			boyd@basser.cs.su.oz
				boyd@necisa.necisa.oz

``When the going gets wierd, the weird turn pro...''

chris@softway.oz (Chris Maltby) (07/08/88)

Yet another reason not to use 'csh'...

$ whatis sh csh whatis
/bin/sh
unset csh
builtin whatis
$ 

-- 
Chris Maltby - Softway Pty Ltd	(chris@softway.oz)

PHONE:	+61-2-698-2322		UUCP:		uunet!softway.oz!chris
FAX:	+61-2-699-9174		INTERNET:	chris@softway.oz.au

drb@praxis.co.uk (David Brownbridge) (07/12/88)

In article <1296@basser.oz> boyd@basser.oz (Boyd Roberts) writes:
>Those coders who believe all the world is a VAX are just
>wrong-wrong-wrong.  

yes Yes YES!

>Somehow High Level Hardware ported 4.2BSD to their box. ...
>... I think I heard rumours about them releasing NFS on it.

I worked on the NFS port when I was at HLH.  The "portable" NFS sources were
certainly written with VAXen in mind.  Imagine my Joy(!) at finding a simple
piece of pointer arithmetic broken by gratuitous casting:

    some_routine()  /* located in an NFS kernel near you */
    {
	    char *a, *b, *c;

	    /* ... code setting b,c to point to parts of an array ... */

	    a = (int) b - (int) c;
    }

Because Orion integer arithmetic is different from pointer arithmetic the
answer delivered in "a" is garbage. Remove the casts and all is ok.

As a historical note, the Orion you mention is now superceded by the
Clipper-based Orion 1/05 and HLH probably posses the most portable set of
BSD/NFS sources in the known universe!


David Brownbridge    +44-225-444700   drb%praxis@ukc.ac.uk
Praxis Systems plc
20 Manvers St
Bath 
Avon
UK    BA1 1PX

maart@cs.vu.nl (Maarten Litmaath) (07/16/88)

In article <2629@newton.praxis.co.uk> drb%praxis@ukc.ac.uk (David Brownbridge) writes:
\	    char *a, *b, *c;
\
\	    a = (int) b - (int) c;

That should be:
	int	a;
	char	*b, *c;

Right?
-- 
I'd rather live in Russia             |Maarten Litmaath @ Free U Amsterdam:
              than in South-Africa... |maart@cs.vu.nl, mcvax!botter!ark!maart