Re: [fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
Steve wrote: Most of this is just pussy footing around the issue. Forgive me if I misrepresent your position here but it seems that you maintain that the implmentation should use a modern instruction set because 1) it generates simpler assembler Yes. 2) it supports Linux and hence has lots of FP developers Partly. and 3) because GCC does so. No. In slightly more detail: 1) The slightly newer opcodes make the 390 look more like the canonical CPUs that most people are used to these days. Since any attempt to implement a port without the help (or at least tolerant supervision) of the core developers is doomed, I think that using recently-introduced facilities is justified. Note that I'm /not/ suggesting going over to a full 64-bit implementation, since this would really complicate a subsequent port back to strict 390 or 370 compatibility (i.e. 32-bit data and 31- or 24-bit addresses). 2) If an existing FPC developer wants to get involved, it's not reasonable to expect him to have to work up the learning curve of MVS before he can actually run the target environment. Linux on Hercules is a no-brainer. 3) GCC is only relevant if external libraries are to be linked, at which point it defines the ABI. I'm /not/ banging the drum unreservedly for GCC and Linux, but IBM (and many other companies) promote it as a universal API and I like to think that they're not total idiots. Similarly, I'm not banging the drum unreservedly for GNU's as assembler etc., since I recognise that a great deal of useful work has been done using IBM's assemblers. But the GNU tools are freely available, while as I understand it IBM (and clone) assemblers aren't: it's not realistic to expect developers to sign a no commercial use agreement etc. since this would infect the entire project in a way that the (L)GPL doesn't. So I think that it's worth considering 32-bit Linux using GNU tools as the initial target. But it's not my choice, I'm only the guy with a foot in both the FPC and mainframe camps who's doing his best to prevent them drifting off in uncomfortable directions. Picking up one of Sven's points: If 360 assembly code can be used on modern processor variants as well I see no problem with targeting that at first only. The point with using Linux as a first target is that you would not need to implement a new RTL, but only the code generator and the processor specific RTL code. The point for gas/ld was simply that we have existing writers for these two, but writing your own writers for IBM specific tools isn't rocket science either... But it's another thing you'd need to implement. There's also the issue of the assembler reader (used, if I understand things correctly, to parse inline assembler mostly in the lower-level bits of the RTL). This seems to cause almost as much problem during development as the assembler writer, and having to support (or at least pass through) complex assembler macros isn't going to make things any easier. Your choice is really nothing to do with me. I don't plan on getting involved. I just don't like to see half-truths and misunderstandings being passed off as the 'one true way'. If I were promoting a one true way I wouldn't be doing my best to keep open the secondary option of getting FPC running on (or at least generating code for) older OSes such as freely-available versions of MVS, VM/CMS and so on using IBM-format assembler. But I don't think these are viable primary targets. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.6.2 gives AV on arm
On 08/15/2013 12:16 PM, Mattias Gaertner wrote: On Thu, 15 Aug 2013 11:45:38 +0200 Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 15 Aug 2013, at 11:26, Mattias Gaertner wrote: On Fri, 09 Aug 2013 23:10:05 +0200 Florian Klämpfl flor...@freepascal.org wrote: Where did you get the CROSSOPT=-dFPC_ARMEL from? It is not needed at all. It's on the wiki: http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface/Android#Building_the_compiler_yourself_in_Linux It only mentions OPT=-dFPC_ARMEL, not CROSSOPT=-dFPC_ARMEL. You are right. I misread the mails and misunderstood Joost statement. Sorry. I think I got confused and mixed the two. Probably because of some other things I've tried with other CROSSOPT options. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
On 23/08/13 09:57, Mark Morgan Lloyd wrote: 1) The slightly newer opcodes make the 390 look more like the canonical CPUs that most people are used to these days. Since any attempt to implement a port without the help (or at least tolerant supervision) of the core developers is doomed, I think that using recently-introduced facilities is justified. Note that I'm /not/ suggesting going over to a full 64-bit implementation, since this would really complicate a subsequent port back to strict 390 or 370 compatibility (i.e. 32-bit data and 31- or 24-bit addresses). If you really think that using gas is going to allow existing 386 family developers to write assembler for a 390 processor then I'm afraid you are in for a sever disappointment. Understanding the assembler is a minuscule part of the skill-set you will require. The newer opcodes do indeed make life simpler, but the environment is still radically different. 2) If an existing FPC developer wants to get involved, it's not reasonable to expect him to have to work up the learning curve of MVS before he can actually run the target environment. Linux on Hercules is a no-brainer. Linux on Hercules is a no-brainer for Linux users; Not all fpc developers will be Linux users. 3) GCC is only relevant if external libraries are to be linked, at which point it defines the ABI. It defines the ABI for Linux. I'm /not/ banging the drum unreservedly for GCC and Linux, but IBM (and many other companies) promote it as a universal API and I like to think that they're not total idiots. Firstly, I am not necessarily proposing that we don't concentrate on Linux initially, in fact it makes a certain amount of sense (In a perverted way :)) My EXAMPLES concentrate on MVS because that's my background. I have never, ever accused IBM of being idiots; Total or any other kind. The universal API that they bang on about is based around C and was, in large part, written by IBM (at least the Linux/390 implementation was). If there is any intention of providing FP on anything other than Linux/390, IBM (and many other companies) will not be involved, it will be people who do this sort of work for a hobby. The alternative, is to leave them to C, a fate I wouldn't wish on anyone. Similarly, I'm not banging the drum unreservedly for GNU's as assembler etc., since I recognise that a great deal of useful work has been done using IBM's assemblers. But the GNU tools are freely available, while as I understand it IBM (and clone) assemblers aren't: it's not realistic to expect developers to sign a no commercial use agreement etc. since this would infect the entire project in a way that the (L)GPL doesn't. I can't speak for all the clone assemblers, some of them, I know are freely available with no restrictions or licenses involved. All of IBM's assemblers are 'licensed' programs with no restrictions AT ALL on the works developed by them. The Assemblers I am suggesting for older OSes have freely available, no charge, no contract licenses. Download and go! So I think that it's worth considering 32-bit Linux using GNU tools as the initial target. But it's not my choice, I'm only the guy with a foot in both the FPC and mainframe camps who's doing his best to prevent them drifting off in uncomfortable directions. As am I. There's also the issue of the assembler reader (used, if I understand things correctly, to parse inline assembler mostly in the lower-level bits of the RTL). This seems to cause almost as much problem during development as the assembler writer, and having to support (or at least pass through) complex assembler macros isn't going to make things any easier. I don't really see why passing macro calls through to an external assembler is any different than passing 'raw' code. It's just text isn't it? Here's some code, assemble it, and be quick about it johnny! Your choice is really nothing to do with me. I don't plan on getting involved. I just don't like to see half-truths and misunderstandings being passed off as the 'one true way'. If I were promoting a one true way I wouldn't be doing my best to keep open the secondary option of getting FPC running on (or at least generating code for) older OSes such as freely-available versions of MVS, VM/CMS and so on using IBM-format assembler. But I don't think these are viable primary targets. It seems to me that the people who are volunteering to do the work run these non-viable environments. I wonder what they think? And, if you keep implying that z/OS is antique and non-viable, IBM's lawyers may be on your rear-end because it is neither. Steve ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
On 23.08.2013 19:44, Steve wrote: 2) If an existing FPC developer wants to get involved, it's not reasonable to expect him to have to work up the learning curve of MVS before he can actually run the target environment. Linux on Hercules is a no-brainer. Linux on Hercules is a no-brainer for Linux users; Not all fpc developers will be Linux users. Mark is talking about compiler developers here. And most of us are either using Linux as the main platform or at least as a platform where we develop for nevertheless. So yes, basically all FPC compiler developers are Linux users more or less. I'm /not/ banging the drum unreservedly for GCC and Linux, but IBM (and many other companies) promote it as a universal API and I like to think that they're not total idiots. Firstly, I am not necessarily proposing that we don't concentrate on Linux initially, in fact it makes a certain amount of sense (In a perverted way :)) My EXAMPLES concentrate on MVS because that's my background. I don't see what would be perverted about that... it might at first restrict the potential user base, but it would only be a first step to allow implementing a more or less working code generator and that other OSes can be tackled. There's also the issue of the assembler reader (used, if I understand things correctly, to parse inline assembler mostly in the lower-level bits of the RTL). This seems to cause almost as much problem during development as the assembler writer, and having to support (or at least pass through) complex assembler macros isn't going to make things any easier. I don't really see why passing macro calls through to an external assembler is any different than passing 'raw' code. It's just text isn't it? Writing assembler by hand is not necessarily the same as letting a compiler write assembler code. At least in FPC the assembly language of each processor is abstracted in operations which are hold in lists and using an assembler writer (of which there can be multiple to target different assemblers) this list is turned into the final file. Here's some code, assemble it, and be quick about it johnny! Was that a Short Circuit reference? O.o Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
Steve wrote: If you really think that using gas is going to allow existing 386 family developers to write assembler for a 390 processor then I'm afraid you are in for a sever disappointment. Understanding the assembler is a minuscule part of the skill-set you will require. The newer opcodes do indeed make life simpler, but the environment is still radically different. You misunderstand me. Most if not all of the other FPC targets use gas as the principal assembler, although in some cases alternatives are also supported. In other words, there are issues of character set, invocation, option format, opcode format, behaviour of pipes and files, and so on. 2) If an existing FPC developer wants to get involved, it's not reasonable to expect him to have to work up the learning curve of MVS before he can actually run the target environment. Linux on Hercules is a no-brainer. Linux on Hercules is a no-brainer for Linux users; Not all fpc developers will be Linux users. Quite frankly, from what I've seen most Windows users would find Linux simpler than one of the *freely* *available* IBM OSes (i.e. MVS, VM/360 sixpack and so on). The alternative, is to leave them to C, a fate I wouldn't wish on anyone. We can agree on that at least, although I must say that C has improved a lot since KR days. I can't speak for all the clone assemblers, some of them, I know are freely available with no restrictions or licenses involved. All of IBM's assemblers are 'licensed' programs with no restrictions AT ALL on the works developed by them. The Assemblers I am suggesting for older OSes have freely available, no charge, no contract licenses. Download and go! OK, that's fair comment. But can you suggest a free (as in both beer and speech) assembler that is available for the various platforms that FPC developers use (Linux on x86, x86-64, PPC, SPARC, ARM; BSD; Windows)? It seems to me that the people who are volunteering to do the work run these non-viable environments. I wonder what they think? And, if you keep implying that z/OS is antique and non-viable, IBM's lawyers may be on your rear-end because it is neither. I prefer to keep things friendly, but if you are going to issue vicarious threats of legal action then I'd much prefer it if you didn't try to put words into my mouth or distort my meaning. I very clearly referred to freely-available versions of MVS, VM/CMS and so on, I really don't see how you manage to mangle that into a derogatory statement about z/OS or any current product. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
Mark Morgan Lloyd wrote: Quite frankly, from what I've seen most Windows users would find Linux simpler than one of the *freely* *available* IBM OSes (i.e. MVS, VM/360 sixpack and so on). To avoid ambiguity: that was a typo, and I meant VM/370 'sixpack'. As background: it appears that IBM didn't embed copyright notices in the source or binary of their early operating systems, with the result that older versions of the DOS, OS, and VM lines are now described as being in the public domain. There's a hobbyist community that runs these under the Hercules emulator, IBM is aware of this but generally keeps its distance. All of these date back to the era when addresses (certainly per-process, and usually system-wide) were 24 bit, i.e. there was a process or system restriction of 16Mbyte of core. Unfortunately, GCC can't compile itself in 16Mb, so somebody's created a patch for the Hercules emulator and for the operating systems which allows one program at a time to allocate storage from above the line, this is referred to as the /380 hack http://mvs380.sourceforge.net/ and hardly anybody's happy about it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
