emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SuperH port


From: Ulrich Mueller
Subject: Re: SuperH port
Date: Wed, 8 Oct 2008 20:22:13 +0200

>>>>> On Wed, 8 Oct 2008, Dan Nicolaescu wrote:

> Given this from your patch:

>> +  Status of SuperH support on NetBSD and OpenBSD is unknown.

> Please do not wily nilly add them back, removing stuff is not something
> we take lightly, so we should not be adding back things that are not
> known to work, nor were requested by actual users.

These are just alternatives in case statements (two lines). No problem
to remove them, but OTOH I think they cannot do any harm.

Also, support for BSD on SuperH had been added less then two years
ago, so why would you expect it to be broken? Especially, since apart
from configure and the machine definition, nothing else is affected.

2006-12-22  Mark Davies  <address@hidden>

        * configure.in: Add support for NetBSD on x86-64, hp800 and sh3el.

>> +  ## SuperH (little endian) Linux-based GNU system
>> +  sh[34]-*-linux-gnu* )
>> +    machine=sh3el opsys=gnu-linux
>> +  ;;
>> +
>> +  ## SuperH (big endian) Linux-based GNU system
>> +  sh[34]eb-*-linux-gnu* )
>> +    machine=sh3eb opsys=gnu-linux
>> +  ;;

> Were both endian versions tested?
> Why have two files, only a single macro should be different between
> them, and it can be conditionally defined.

No other machine file does this. But maybe it is a good idea to get
rid of WORDS_BIG_ENDIAN in general, given the following comment in
configure.in:

dnl This could be used for targets which can have both byte sexes.
dnl We could presumably replace the hardwired WORDS_BIG_ENDIAN generally.
dnl AC_C_BIGENDIAN

> Simply adding the file back is not OK, work has been done to clean up
> and simplify these files.

<rant> That work would have been better invested to get rid of the
antediluvian build system with its hardwired config files. </rant>

And if you had done a diff to the file in the CVS attic, then you
would have noticed that I already did some cleanup to bring the file
in line with the changes in the other machine files. Of course it is
possible that I've missed something.

>> +#define LOAD_AVE_TYPE long
>> +#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)

> These are not needed for GNU/Linux, remove them.

As far as I understand it, the m/*.h files are supposed to be OS
independent?

Concerning EXPLICIT_SIGN_EXTEND, CANNOT_DUMP, VIRT_ADDR_VARIES,
HAVE_ALLOCA, and NO_REMAP, I'll remove the corresponding lines and
have it tested again.

However, from your rather discouraging reply I have the impression
that this port is not wanted?

Best regards
Ulrich




reply via email to

[Prev in Thread] Current Thread [Next in Thread]