[9fans] Fresh (relatively speaking) Graphviz

[9fans] Fresh (relatively speaking) Graphviz

[lucio]

Like all my APE-based efforts, I'm seldom satisfied with the results,
possibly because I don't really try hard enough.

This one is another baby step: from Graphviz 1.10 to Graphviz 1.16,
with the addition of FreeType and GIF.

I've checked dot/FreeType with some unusual fonts (bard, nadiannb) and
it seems fine.  GIF results in colours that do not make sense, but all
things considered I think that's due to the renderer (page -w), for
reasons someone else may want to investigate (it seems fine with "gif"
instead of "page").  Indeed, rotating JPEG images with "page -w" also
falls apart, but I think "page" has been damaged in the last few
months and needs some attention.

It may help others to know that my approach has been to ./configure
the distribution under NetBSD, add mkfiles to some pertinent
directories (q.v.) and with a little manual help actually generate the
entire distribution.  A recent copy of FreeType2 had already been
constructed for the purpose, I needed the GD library included in the
Graphviz distribution to provide all the promised features.  Lefty and
possibly other tools and utilities I am not familiar with have been
totally neglected, any assistance in getting these off the ground is
perfectly welcome.  Future developments will be to do the same with
"2.16.1", whether I'll ever figure out why I cannot produce equivalent
results without help from NetBSD remains undecided.

Again, I won't encumber "sources" with my efforts unless there is
demand for it.  Even then, binaries may come first, depending on
requests.

++L

PS: This is also part of the zlib->jpeg->libpng series I use to build
libtiff and libgeotiff and, some day soon, a tiff2pic that actually
works.  Problem with the "tiff2pic" is that I need to render Surveyor
General maps and aerial photographs and storing hundreds of megabytes
in memory becomes unwieldy.  I'm not qualified to address such issues,
rendering is somewhat less than a hobby to me.

PPS: I guess it's graphviz 2.16.1 or tiff2pic or back to GCC that
comes next.  GCC scares me, what with the C++ library, the need to
produce a fresh APE library using documentation about the function
call sequence that I cannot find anymore and, of course, moving on to
GCC 4.  Oh, I also need to know that my translation from:

> cpu% cat getcallerpc.s
> TEXT getcallerpc(SB), $0
> 	MOVL	v+0(FP), AX
> 	MOVL	-4(AX), AX
> 	RET

to:

> cpu% cat getcallerpc.s
> .globl	getcallerpc
> getcallerpc:
> 	movl	0(%esp),%edx
> 	movl	-4(%edx),%eax
> 	ret

is in fact correct.  I don't believe that EAX can be used as an index
register, but I haven't programmed on the i386 at all, I stopped with
the 8086, using Intel's own conventions.

Re: [9fans] Fresh (relatively speaking) Graphviz

[Russ Cox]

cpu% cat getcallerpc.s
TEXT getcallerpc(SB), $0
	MOVL	v+0(FP), AX
	MOVL	-4(AX), AX
	RET

> .globl	getcallerpc
> getcallerpc:
> 	movl	0(%esp),%edx
> 	movl	-4(%edx),%eax
> 	ret

not quite.  0(%esp) is going to be the saved %eip.

getcallerpc:
	movl 4(%esp), %eax
	movl -4(%eax), %eax

or

uint
getcallerpc(void *a)
{
	return ((uint*)a)[-1];
}

russ

P9GCC: APE library (Was: [9fans] Fresh (relatively speaking) Graphviz)

[lucio]

> not quite.  0(%esp) is going to be the saved %eip.
>
> getcallerpc:
> 	movl 4(%esp), %eax
> 	movl -4(%eax), %eax

Thank you, that will almost certainly save me a lot of heartache.

++L

PS: Busy rebuilding the APE libraries right now, you'll be amazed how
much has changed since GCC 3.0!  And how painful it is to track the
changes.

Re: [9fans] Fresh (relatively speaking) Graphviz

[lucio]

> not quite.  0(%esp) is going to be the saved %eip.
>
> getcallerpc:
> 	movl 4(%esp), %eax
> 	movl -4(%eax), %eax

Just a thought: this is in the GCC function call context, which is
different from the P9 compilers'.  Does the above still apply?

I know I saw dhog's documentation of the GCC function call convention,
but I don't seem to have a copy.  Was it on this list rather than
within the distribution?

++L

Re: [9fans] Fresh (relatively speaking) Graphviz

[Russ Cox]

>> getcallerpc:
>> 	movl 4(%esp), %eax
>> 	movl -4(%eax), %eax
>
> Just a thought: this is in the GCC function call context, which is
> different from the P9 compilers'.  Does the above still apply?

yes, it does.  standard x86 gcc and plan 9 use the
same conventions for how function arguments get
passed.

the only difference in calling convention between
gcc's default behavior on x86 platforms and the
plan 9 compilers is that gcc has a few callee-saved
registers, while the plan 9 compilers have none.
i don't know whether, in the gcc port for plan 9,
david changed the register saving conventions to
match plan 9's.  i carefully avoided the issue in the
snippet above, trashing only the return register %eax.

very few programs care if getcallerpc is broken,
and it is never a bottleneck.  if it is really bothering
you, the c function i posted is certainly correct and
avoids writing assembly.

russ

Re: [9fans] Fresh (relatively speaking) Graphviz

[lucio]

> i don't know whether, in the gcc port for plan 9,
> david changed the register saving conventions to
> match plan 9's.  i carefully avoided the issue in the
> snippet above, trashing only the return register %eax.

I remember distinctly that he was obliged to recompile the entire APE
library to make sure it obeyed the GCC function call conventions, I
thought it involved considerable differences.  But, as I mentioned, I
lost track of his description and I don't think I ever really
understood the details :-(

++L

Re: [9fans] Fresh (relatively speaking) Graphviz

[Charles Forsyth]

> the only difference in calling convention between
> gcc's default behavior on x86 platforms and the
> plan 9 compilers is that gcc has a few callee-saved
> registers, while the plan 9 compilers have none.

i thought gcc typically required BP to be used as a frame pointer,
whereas 8c simply uses it as another register, which is particularly
helpful on the grotty x86.  (general-purpose registers? pah!)

Re: [9fans] Fresh (relatively speaking) Graphviz

[lucio]

> i thought gcc typically required BP to be used as a frame pointer,
> whereas 8c simply uses it as another register, which is particularly
> helpful on the grotty x86.  (general-purpose registers? pah!)

I don't think that's mandatory, but I am no authority.  Using the MSC
compiler, back in 8086 days, one set BP to SP and used it as a stack
frame pointer.  It's conceivable that GCC used the same convention,
all C compilers i was familiar with on the 8086 behaved like that.

++L

Re: [9fans] Fresh (relatively speaking) Graphviz

[lucio]

> very few programs care if getcallerpc is broken,
> and it is never a bottleneck.  if it is really bothering
> you, the c function i posted is certainly correct and
> avoids writing assembly.

I'll keep that in mind, thank you.

I'm now getting to the 386 syscalls.  The following comment in the
mkfile needs addressing.  Suggestions?

# _SEEK is broken, but we currently don't use it.
# GCC uses eax,edx to return a vlong
#
#			if(~ $i _SEEK) {
#				echo 'CMPL AX,$-1
#				JNE 4(PC)
#				MOVL a+0(FP),CX
#				MOVL AX,0(CX)
#				MOVL AX,4(CX)'
#			}

Much appreciated.  How much of the p9p work am I duplicating right
now?

++L

P9GCC progress (Was: [9fans] Fresh (relatively speaking) Graphviz)

[lucio]

Apologies. I forgot to change the subject line...

> I'm now getting to the 386 syscalls.  The following comment in the
> mkfile needs addressing.  Suggestions?

++L

Re: [9fans] Fresh (relatively speaking) Graphviz

[Russ Cox]

> I'm now getting to the 386 syscalls.  The following comment in the
> mkfile needs addressing.  Suggestions?

Change the loop to rename the generated assembly
stub __seek and treat it like any other system call
(no special code; just the name change).

Then add this C function:

	int _seek(vlong*, int, vlong, int);

	vlong
	seek(int fd, vlong off, int whence)
	{
		vlong ret;
		if(_seek(&ret, fd, off, whence) == -1)
			return -1;
		return ret;
	}

You should never ask "how do I write this in assembly?"
You should ask "how do I *not* write this in assembly?"

Russ

P. S.  You might also change gcc not to prefix all the
C functions with underscores.  (I'm sure there's an option.)
Real systems gave that up a long time ago.