dag@chinet.UUCP (Daniel A. Glasser) (04/15/88)
In article <146@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >So why should we force these MS-DOSisms on the rest of the C-speaking >world? This is yet another kludge around the Intel iAPX?86 >architecture (or lack thereof :-), just like "near" and "far". Tell >me, what does "near" mean on a 68000 system? I can call C routines >from the Unix fortran compiler WITHOUT declaring the C routine to be >of "fortran calling sequence." Let's not put these kludges in a C >language standard. If your programming environment needs them, let >them be (non-portable) extensions to the standard needed to support >your (non-) operating system! Although I agree fully with Wes's comments about MS-DOSisms, the common extensions 'near' and 'far' can be used to some benifit in a 68000 compiler. The architecture of the 68000 is such that PC Relative calls and data references are faster and smaller than their absolute counterparts, and on systems with runtime relocation reduce the load time and load module size by an additional amount. With the addition of these two keywords, a compiler can be directed to generate one or the other type of reference by default and the use the keyword to override this. That is not to say that I believe that these keywords should be added to the standard, but that they should be listed as a common extension so that their usage is consistant between different envionments. (Although the useage would be similar between the M68000 and I80x86 environments, the meaning would be quite different.) The compiler that I work on for the M68000 does not support this extension, but does support generation of either PC relative or absolute references for data fetches and calls. Use of the PC relative option is very tricky because the range of the fetches must be +-32k from the instruction, and sometimes the functions are too far away. With the addition of the near and far extensions, I could simply (with a knowlege of the structure of my program) declare the far away functions to be far, compile with all function calls defaulting to PC relative, and compile the modules that get loaded at the end with PC relative data references. (The environment I work on has the data segment directly following the text segment and the bss directly after that.) (The above example is supposed to demonstrate the difference in meaning of these keywords for different environments.) Disclaimer: I speak for the millions of subjigated lifeforms that are forced to unite to form my body. They may not agree with me, but I am a heartless tyrant. I make no claims to speak for any other conglomerations of protoplasm, micro or macro. -- Daniel A. Glasser dag@chinet.UUCP One of those things that goes "BUMP!!! (ouch!)" in the night. ...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag
dg@lakart.UUCP (David Goodenough) (04/18/88)
From article <4811@chinet.UUCP>, by dag@chinet.UUCP (Daniel A. Glasser): > In article <146@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >>So why should we force these MS-DOSisms on the rest of the C-speaking >>world? ..... Tell me, what does "near" mean on a 68000 system? ..... > > Although I agree fully with Wes's comments about MS-DOSisms, the common > extensions 'near' and 'far' can be used to some benifit in a 68000 compiler. > The architecture of the 68000 is such that PC Relative calls and data > references are faster and smaller than their absolute counterparts, ..... Yes, however that should be the job of the linker to spot which should be used - someting like the jbr pseudo instruction on the PDP-11: it created a short branch (+-127) if it could otherwise it created a long branch. With the way optimizing compilers and related products are being created, I refuse to believe that this is impossible. -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!adelie!cfisun!lakart!dg +-+-+ | +---+
henry@utzoo.uucp (Henry Spencer) (04/24/88)
> Yes, however that should be the job of the linker to spot which should be > used - someting like the jbr pseudo instruction on the PDP-11: it created > a short branch (+-127) if it could otherwise it created a long branch... Note, though, that it was the assembler, not the linker, that did this on the 11. Doing it at link time is not impossible, but it is harder, and it's effectively impossible when the compiler writer is working with an existing linker with rigid specs. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry