On 01/23/2012 05:57 PM, Andreas Tille wrote:
On Mon, Jan 23, 2012 at 04:58:50PM -0500, Bhaskar, K.S wrote:
[KSB] Even though both 32-bit and 64-bit GT.M for x86 are built from
the same source code, the GT.M code generators are a couple of
generations apart in design evolution. The code generator for
32-bit is perhaps the most primitive version still in use and the
64-bit is one of the most modern. The 32-bit code generator
generates object code in an old format (I think XCOFF). In both
cases, the GT.M dynamic linker knows how to dynamically link .o
files, but only the 64-bit .o files are in a format that ld
understands, and only the 64-bit GT.M dynamic linker knows how to
link object modules in .so shared libraries.
Any chance that such outdated build methods for 32-bit will be fixed in
the not so far future (considering the amount of developers Luis was
mentioning this should be doable IMHO).
[KSB] Not likely - it would be a major project, especially because the
32-bit architecture doesn't have enough registers.
GT.M dynamically compiles and links routines (this is a feature of
M/MUMPS). So, a process can dynamically link and execute a module XYZ,
then create a new module XYZ, and link the new module - so that when it
now executes XYZ, it executes that new module. The only restriction is
that when it links the new XYZ, the old XYZ cannot be on the stack. The
compiler and linker are in the GT.M run-time system resident in every
process. So, in one sense, the object file format does not really matter
because the GT.M compiler generates it and the GT.M linker dynamically
links it.
In another sense, it does matter. When the GT.M linker links a routine
in this way, it takes heap space for the code. If there are 3000
processes each linking 100MB worth of code (and GT.M runs applications
that are much bigger), that is 300GB of heap space. So, the newer code
generator puts the object code in a format that ld can place in a shared
library The GT.M linker still needs to link that module, and it still
has structures in heap space to allow the dynamic relinking, but the text
of the object code is shared between processes. It is able to do this
because the 64-bit architecture has enough registers. Incidentally, our
internal stress tests create shared libraries with over 4GB of object
code (from something on the order of 200000 object modules) for a process
to link.
Of course, there are ways to work around a lack of registers, but it will
involve the same amount of work as porting GT.M to a new architecture,
and is a major project. If we had the funding, I'd rather see us put the
investment into an ARM port.
I'll look at converting the csh scripts.
Good.
[KSB] Although I am personally a bash user, the entire GT.M
automation infrastructure is build around tcsh (not even csh). It
may be easier to use tcsh for now and not try to convert the scripts
till later.
While this is finally your decision I'd recommend replacing it where
possible anyway. You can expect to have a POSIX shell installed on any
UNIX machine (whatever GT.M developers prefer as login shell). Relying
on some specific shell just manifests the exceptional (=historically
grown) speciallities of GT.M. I can not see a reason to not drop this
if possible.
[KSB] Our GT.M build and test infrastructure has hundreds of tcsh shell
scripts, some of which are extremely complex. It's highly unlikely that
we will ever change. To us, this would be like changing the side of the
road we drive on - pain with no gain.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
BTW, keeping csh scripts around is just a compromis. :-)
Kind regards
Andreas.
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
