Re: Drawterm problems

["Russ Cox" <rsc@swtch.com>]

[bcc: everyone but Martín]

Thanks for your note.  Drawterm has been run successfully
on the MIPS under SGI IRIX and the Sparc under Solaris
and the 64-bit Alpha under Digital UNIX.  I'm afraid that
I have not tried Linux on those platforms, nor gcc on some,
so there will be problems.

Drawterm also predates the widespread availability of
correct pthread implementations, so it tries to do many
things itself that it might now be able to use libraries for.

I'm happy to offer help porting it to Linux/gcc on the
architectures you care about.

>  First problem: it doesn't compile on mips at all, the assembly code
>  seems invalid. In [0] you can find a proposed patch.

That seems fine.

>  Second problem: the arch handling is quite fragile, and it doesn't
>  work for sparc under linux [1] (uname -m is sparc64, not sun4u), for
>  example. But the biggest problem is that there are no provisions for
>  other architectures. I have prepared a big patch for this, see below.
>
>  Third: segfaults on amd64, possibly other arches that I couldn't test.
>  After a lot of guessing, I suspected of these constructs in lib.h:
>
>  typedef int            p9_long;
>  #define long  int
>
>  Changing them to match longs with longs made the segfault go away, as
>  amd64 uses 64bits for longs and the included libX.h was botched
>  because of the "#define long int". But then it popped many type errors
>  all around, since there are many inconsistencies (for example,
>  function prototypes that doesn't match exactly the fuction
>  definitions) and all the code assumes long==int. I'm trying to fix
>  this, but the problem is very deep: there are many places where size
>  specific types should be used instead of longs and ints.

As you say, this is a very deep problem, especially in
the graphics code.  It will take you a very long time to find
all the places that say long but mean int32; the #define
is both simpler and helps keep the drawterm sources more
similar to the Plan 9 kernel, so that changes can be incorporated.

The #define is safe provided all system headers are included
before the drawterm headers that redefine long.  If there are
files in which this is not true, those need to be changed.

>  I'm including the arch-related patch: it disables all the posix-*/
>  code (except for the x86 hashing routines, which are now conditionally
>  complied from libsec) and instead creates a libmachdep directory with
>  a tas.c file. In tas.c it tries to use the fairly new builtin atomic
>  operations, and falls back to assemby if it's available. Also, the
>  getcallerpc function is replaced with other gcc builtin, but I haven't
>  made provisions for fallback to assembly here as I think that the
>  builtin I'm using is widely available and that would have made the
>  patch very complex.

It should be just fine to return 0 for getcallerpc,
use a pthread_mutex_t instead of tas, and use the
C versions of the hash functions.  That will make the
code still more portable without introducing any
dependencies on gcc.

I'll follow up in private mail about the patch details.

Russ