On 01/23/2012 05:57 PM, Andreas Tille wrote:
[KSB] Not likely - it would be a major project, especially because the 32-bit architecture doesn't have enough registers.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).
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.
[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.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.
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.