Portability

[Pippijn van Steenhoven]

Hi,

I am currently building the autoconf checks and thinking about a few
portability issues. I don't know how important each of them is anymore.
Here is a list of #ifdefs which I am unsure about:

  CC_no_void_pointer: Are there any compilers that don't support void*
    anymore?
  CC_noncanonical_pointer: Does anybody still use segmented
    architectures? (8086, anyone?)
  CC_no_token_paste: Are there any preprocessors that don't support the
    token paste operator (##)?
  CC_no_empty_file: Were there ever compilers that *error* on empty
    files? If yes, are there any left?
  CC_short_pointer: Does anybody still use MSDOS?

Another question is whether these questions are actually relevant. Should
I just go for maximum portability and try being compatible with every
system in the world? I think not. I think it's better to concentrate on
current platforms. As far as I am aware of, Aldor does not run on FreeBSD
6 and OpenSolaris. I have direct access to a NetBSD machine at home and I
am planning to install OpenSolaris in a virtual machine. Windows is
already in my virtual machine. I work on debian etch. I have remote
access to a VMS system (which I don't understand.. I can't handle VMS)
and a FreeBSD 6.2 system.

Systems:
  FreeBSD 6.2 (i386/amd64), NetBSD 4.0 (i386/amd64),
  OpenSolaris 2008 (i386/amd64), Linux 2.6 (i386/amd64),
  Windows XP 2600 (i386)
 
Compilers:
  GCC 3.4 (i386/amd64), GCC 4.1 (i386/amd64), MSVC 9 (i386),
  ICC (i386/amd64)

In addition to that, I have access to:
  HP OpenVMS 8.3 (ia64), HP HP-UX 11 (ia64/hppa)


That makes up for a few combinations. Theoretically, I could use dosbox
on Linux and port aldor to that. The question is whether that is desired.
Of course it is "cool" to be very portable, but it is also very uncool to
be nonportable to FreeBSD.

What other combinations can people offer for testing and what
combinations are interesting? I want to make a list of systems that work
and systems that we want to have working.

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Stephen Watt]

Pippijn,

These questions certainly are useful.

I agree that we don't want an undue amount of baggage keeping Aldor
running on places that are never used anymore.  The dividing line I
would use in deciding these questions would be:  Is this an issue that
might recurr?

So, for example,  it may be that we will never use again a platform
with a severely broken C compiler so that CC_no_void_pointer and
CC_no_token_paste and CC_no_empty_file are obsolete.

On the other hand, segmented architectures keep coming back in
different guises.  We now have NUMA, and the C standard does not
require that pointers be cannonical, so I would fear that we have to
keep the pointer cannonicalization but restrict its use to low-level
code, e.g. the garbage collector or EQ hashtables.

Yours,

Stephen


2008/8/16  <pip88nl@...>:

> Hi,
>
> I am currently building the autoconf checks and thinking about a few
> portability issues. I don't know how important each of them is anymore.
> Here is a list of #ifdefs which I am unsure about:
>
>  CC_no_void_pointer: Are there any compilers that don't support void*
>    anymore?
>  CC_noncanonical_pointer: Does anybody still use segmented
>    architectures? (8086, anyone?)
>  CC_no_token_paste: Are there any preprocessors that don't support the
>    token paste operator (##)?
>  CC_no_empty_file: Were there ever compilers that *error* on empty
>    files? If yes, are there any left?
>  CC_short_pointer: Does anybody still use MSDOS?
>
> Another question is whether these questions are actually relevant. Should
> I just go for maximum portability and try being compatible with every
> system in the world? I think not. I think it's better to concentrate on
> current platforms. As far as I am aware of, Aldor does not run on FreeBSD
> 6 and OpenSolaris. I have direct access to a NetBSD machine at home and I
> am planning to install OpenSolaris in a virtual machine. Windows is
> already in my virtual machine. I work on debian etch. I have remote
> access to a VMS system (which I don't understand.. I can't handle VMS)
> and a FreeBSD 6.2 system.
>
> Systems:
>  FreeBSD 6.2 (i386/amd64), NetBSD 4.0 (i386/amd64),
>  OpenSolaris 2008 (i386/amd64), Linux 2.6 (i386/amd64),
>  Windows XP 2600 (i386)
>
> Compilers:
>  GCC 3.4 (i386/amd64), GCC 4.1 (i386/amd64), MSVC 9 (i386),
>  ICC (i386/amd64)
>
> In addition to that, I have access to:
>  HP OpenVMS 8.3 (ia64), HP HP-UX 11 (ia64/hppa)
>
>
> That makes up for a few combinations. Theoretically, I could use dosbox
> on Linux and port aldor to that. The question is whether that is desired.
> Of course it is "cool" to be very portable, but it is also very uncool to
> be nonportable to FreeBSD.
>
> What other combinations can people offer for testing and what
> combinations are interesting? I want to make a list of systems that work
> and systems that we want to have working.
>
> Pippijn
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIpvjOJc+zqGNdDgoRAm4TAJ9qCY5muR9TuWAIBHQWfctn32XzVwCdHKEB
> Cb1fCri1zLOrUeRKv8bmtRc=
> =uuJQ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Aldor-l mailing list
> Aldor-l@...
> http://aldor.org/mailman/listinfo/aldor-l_aldor.org
>
>

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

On Sat, Aug 16, 2008 at 12:27:04PM -0400, Stephen Watt wrote:
> So, for example,  it may be that we will never use again a platform
> with a severely broken C compiler so that CC_no_void_pointer and
> CC_no_token_paste and CC_no_empty_file are obsolete.

They are possibly obsolete and possibly baggage, but they are abstracted
away, so does it hurt? The token paste is being used by librona, so that
already requires a compiler that supports it. The no empty file
requirement is definitely baggage. It makes files ugly (ThatsAll). The
no-void-pointer is no baggage, really. It's hard to say what is and what
is not obsolete.

> On the other hand, segmented architectures keep coming back in
> different guises.  We now have NUMA, and the C standard does not
> require that pointers be cannonical, so I would fear that we have to
> keep the pointer cannonicalization but restrict its use to low-level
> code, e.g. the garbage collector or EQ hashtables.

NUMA.. Is there any way someone can test aldor on NUMA?

By the way, I started a table of portability issues on my website:
http://xinutec.org/~pippijn/en/projects_aldor_porting.xhtml
I wanted to do it on the algebraist wiki, but it doesn't support the
mediawiki formatting I wanted (coloured cells in tables) or maybe I just
didn't find the origo way to do it.

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

Stephen,

in cport.h, I see #ifdef CC_vax_endian but CC_vax_endian is never
defined. Should I add checks for vax endianness?

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

On Sat, Aug 16, 2008 at 10:39:48PM +0200,  wrote:
> in cport.h, I see #ifdef CC_vax_endian but CC_vax_endian is never
> defined. Should I add checks for vax endianness?

Hmm.. I was just thinking, is VAX not little endian? I thought it was.
Should PDP endianness (3412) be supported?


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

Now I have three questions:

- does aldor want to support systems where CHAR_BIT != 8?
- if it does have to support them, how do I reliably find out the
  endianness? either way, endianness doesn't exist on platforms where
  sizeof (char) == sizeof (long) but then again, aldor doesn't want to
  support platforms where this is the case (see CC_second_largest_is_int)
  for why.
- can I require the system to have an integral datatype with
  sizeof (T) == 4?


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

I believe the documentation imposes the following two constraints on
datatype sizes:

1.    sizeof (long)  > sizeof (int)
   or sizeof (long) == sizeof (int) and sizeof (int) > sizeof (int)

2.    sizeof (char *) == sizeof (short)
   or sizeof (char *) == sizeof (long)

This means that:

- sizeof (long)   >= 2
- sizeof (int)    >= 1
- sizeof (short)  >= 1
- sizeof (char *) >= 1 (may be 1 in medium and smaller memory models)

Are these really all the constraints I have? I *need* some test machines
for this stuff :-\. Aldor's code seems to want to be almost as portable
as C itself. That's funny, because it doesn't even run on FreeBSD :(. I
don't want to remove the current portability, though. At this point, I
just want to remove obsolete compiler-brokenness-checks.

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Stephen Watt]

THis is good what you are doing.   Aldor used to run on FreeBSD about
10 years ago, but the port was not kept current.   What is not working
now?    -- Stephen

2008/8/16  <pip88nl@...>:

> I believe the documentation imposes the following two constraints on
> datatype sizes:
>
> 1.    sizeof (long)  > sizeof (int)
>   or sizeof (long) == sizeof (int) and sizeof (int) > sizeof (int)
>
> 2.    sizeof (char *) == sizeof (short)
>   or sizeof (char *) == sizeof (long)
>
> This means that:
>
> - sizeof (long)   >= 2
> - sizeof (int)    >= 1
> - sizeof (short)  >= 1
> - sizeof (char *) >= 1 (may be 1 in medium and smaller memory models)
>
> Are these really all the constraints I have? I *need* some test machines
> for this stuff :-\. Aldor's code seems to want to be almost as portable
> as C itself. That's funny, because it doesn't even run on FreeBSD :(. I
> don't want to remove the current portability, though. At this point, I
> just want to remove obsolete compiler-brokenness-checks.
>
> Pippijn
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIp0ZSJc+zqGNdDgoRAqKhAJ996YKQKXMrNYpM7g7rTNQebRP9qwCg2JPe
> dnzZ0fNFaHObvcYqZZst/tA=
> =9EJb
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Aldor-l mailing list
> Aldor-l@...
> http://aldor.org/mailman/listinfo/aldor-l_aldor.org
>
>

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

On Sat, Aug 16, 2008 at 07:03:23PM -0400, Stephen Watt wrote:
> THis is good what you are doing.   Aldor used to run on FreeBSD about
> 10 years ago, but the port was not kept current.   What is not working
> now?    -- Stephen

It crashes.. I didn't investigate any further, but I will, tomorrow.

> 2008/8/16  <pip88nl@...>:
> > I believe the documentation imposes the following two constraints on
> > datatype sizes:
> >
> > 1.    sizeof (long)  > sizeof (int)
> >   or sizeof (long) == sizeof (int) and sizeof (int) > sizeof (int)

Correction:
      or sizeof (long) == sizeof (int) and sizeof (int) > sizeof (short)


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

On Sat, Aug 16, 2008 at 07:03:23PM -0400, Stephen Watt wrote:
> THis is good what you are doing.   Aldor used to run on FreeBSD about
> 10 years ago, but the port was not kept current.   What is not working
> now?    -- Stephen

It's not recognised as being OS_UNIX. I fixed that, but now it doesn't
know how to determine the text segment's begin/end addresses. Does anyone
here know about that?

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

On Mon, Aug 18, 2008 at 07:47:23AM +0200,  wrote:
> It's not recognised as being OS_UNIX. I fixed that, but now it doesn't
> know how to determine the text segment's begin/end addresses. Does anyone
> here know about that?

I found it.. now I'm having other issues, but they don't seem
unresolvable.


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Pippijn van Steenhoven]

Hi,

during the Aldor Workshop, I talked with Bill Page about portability.
There are operating system abstraction layers for various systems
including VMS and DOS. Should these still be supported? Which of the
others should still be supported? I recently gained access to an OpenVMS
cluster, but I didn't find a way to build aldor on it, yet. There is no
GNU make on there, only MMS and MMK. Also, as far as I can see, the
garbage collector does not work on VMS.

A major issue on VMS is that there can be no configure script. There is
no bourne shell on that. The aldor build system as provided by aldor.org
also heavily relies on the bourne shell existing on the system (or nmake
for windows). Can anyone tell me how to build aldor on VMS? I want to see
whether it runs at all..

By the way, on FreeBSD, aldor still segfaults and I can't really work on
it. Building aldor in the VM running FreeBSD takes over an hour.

Pippijn


_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

[Bill Page-7]

2008/8/29  Pippijn:
>
> during the Aldor Workshop, I talked with Bill Page about portability.
> There are operating system abstraction layers for various systems
> including VMS and DOS. Should these still be supported? Which of
> the others should still be supported?

My answer to both VMS and DOS is "no". I really cannot imagine anyone
seriously interested in running Aldor on these legacy systems. I think
narrowing the number of supported platforms and focusing on one
standard build system of all of them would have some important
advantages.

> I recently gained access to an OpenVMS cluster, but I didn't find a
> way to build aldor on it, yet. There is no GNU make on there, only
> MMS and MMK. Also, as far as I can see, the garbage collector does
> not work on VMS.
>

I used VMS on VAX hardware for many years and in spite of it's
reputation for reliability, I can not say that I miss it at all. :-) I
think there a much more interesting ways to spend one's time these
days.

> A major issue on VMS is that there can be no configure script. There is
> no bourne shell on that. The aldor build system as provided by aldor.org
> also heavily relies on the bourne shell existing on the system (or nmake
> for windows). Can anyone tell me how to build aldor on VMS? I want to
> see whether it runs at all..
>

I strongly recommend against it but well, if you **really* want to do
this, I think the only practical way might be using OpenVMS tools:

http://h71000.www7.hp.com/openvms/freeware/index.html

unfortunately the OpenVMS itself does not include a C compiler. So you
will need something proprietary from HP:

http://h71000.www7.hp.com/commercial/c/c_index.html

> ...

Regards.
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org