I seem to have messed up the subject lines on some of these posts. Sorry.
>> It's not any problem to move the binary itself, but there is more required >> than the binary itself in order to produce an executable load module on any >> OS version. (I can't comment on VM or DOS cause they are a mystery to me). >> An OS binary consists of more than the binary and I know of no way to build >> that information on Linux or Windows. >> > > That's not the case when the target is Linux: as with all distreaux and > variants, the program compiles to a single file: > Yeah. Hence the repeated references to OS :) I have had no contact with Linux/390 so I can't possibly comment. > > We look forward to your notes. My understanding is that at least one > variant of FPC (the one targeting x86) can use multiple assembler > notations, so the exact format of the assembly source might turn out not > to be a problem. More of a problem would be is 370 Assembler conventions > turned out to be incompatible with FPC code generation. That sounds useful. > > Once a initial port to 370 has been made and the assembler output > > generator is implemented (which means that the compiler can basically > > generate 370 capable assembler files) this is rather easy as FPC can > > generate "link on target" scripts (and AFAIK also "assemble on target"). That too! > Assuming that the target operating system has any concept of an > executable script. Steve's already told us that you can't generate a > binary externally, and it might turn out that the compiler will have to > generate a JCL (or comparable) deck which is then processed in some way > on the target rather than being executed directly. JCL IS an executable script. But there are terminal based scripting facilities available too. Running such a task on a terminal however, would have less storage available to it. -- Regards, Steve _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
