Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8365

Re: 64-bit detection

Show all headers | View raw

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1qstw1myfako5@localhost...
> On Mon, 13 Jul 2015 07:34:46 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
>> news:op.x1o8dle4yfako5@localhost...
>>> On Sun, 12 Jul 2015 14:04:51 -0400, James Harris 
>>> <james.harris.1@gmail.com> wrote:

>> IMO compilers should not call anything other than what they are told 
>> to.
>
> I agree, but I accept reality as-is.

So says the man who is developing his own toolchain!

Besides, IME so far a good compiler will emit only what it is told to. 
At least that's with the exception of calling a stack checker on entry 
to a function. As mentioned before, that topic is something I may need 
to come back to.

DJGPP and OpenWatcom may call lots of things in the background. I don't 
know. But bcc and gcc seem, so far, to do just what they are told. DJGPP 
is a version of gcc, isn't it? So where did the DPMI stuff come in? Is 
DPMI a non-core add-on to DJGPP, and thus optional, or is it intrinsic 
and impossible to get away from if you use DJGPP?

>>>> RP: specific processor mode.
>>>>
>>>> If you mean 16-bit or 64-bit etc then that's OK. Emitting code for 
>>>> a  particular CPU mode is what the compiler *should* do.
>>>
>>> Yes, but you don't get to decide how that mode is set up.  You're 
>>> stuck
>>> with whatever the C compiler needs for generating code for the host.
>>>
>>> E.g., 32-bit, ring-3, code/data segments limited to 1MB in size ...
>>
>> I don't understand this. IMO the compiler should know nothing about 
>> what  ring the code will run in and the memory requirements of the 
>> app are  what they are.
>
> The compiler has to generate addresses for the code and select
> instructions to emit. Those are dependent on the mode and processor
> set up for that mode.

OK.

> E.g., addresses are dependent on base address
> of the segment in the descriptor.

Wouldn't relocation fix that?

Of course, an OS image might be loaded in bare form and therefore need 
to relocate itself so needing to begin with some relocation code.

> Various instructions are dependent
> on privilege levels.  I.e., the compiler may need to emit them for
> ring-0 kernel code, but not emit them for ring-3 user code, if the OS
> is set up in that manner.

You can always call an assembly routine if you want to run privileged 
instructions. The compiler can just do the universal stuff and not need 
to concern itself with ring0-only instructions.

>>>> RP: position-independent code or not.
>>>>
>>>> This is a hot topic in that it is something I have been looking at 
>>>> in  the past couple of days. I have looked at how compilers emit 
>>>> code for  x86 and ARM for both stand alone apps (not PIC) and 
>>>> shared libraries  (PIC). I am not sure whether or not I like the 
>>>> existing approach  which  makes PIC slow and bulky but I can at 
>>>> least see why it is done  that way:  shared libraries need to 
>>>> access their static and global  data, if they  have any. I may have 
>>>> an answer to this that is not  compiler-depdendent  but it would 
>>>> make this post overlong so I won't  include it just now.
>>>
>>> I mentioned this one because of DJGPP apps versus OpenWatcom apps.
>>> DJGPP uses a split memory model.  The app's virtual starting address
>>> is zero, no matter where it's loaded,
>>
>> But can be relocated, I hope, without having to set segment registers 
>> to  point to the start of the image...?
>
> Relocated, yes.
>
> Not having to set a descriptor base address, no, AIUI.  The addresses 
> in
> the image start at zero.
>
> I think PIC code would be needed to not have to adjust descriptors.
>
> Perhaps paging could solve this, but I'm not sure how at this point.

I don't know enough about DGJPP or OW to comment and I suspect you are 
happy with what you have. That said, if you want to try to convert to 
portable/gcc source I would be interested to try and help. The whole 
DPMI stuff has always been a bit of a mystery and it's something I would 
genuinely be interested in - at least in learning how to convert away 
from! Otherwise I'll leave the subthread there.

...

>>> The compiler itself is definately going to be OS dependent just to 
>>> read
>>> and write files or do stdio/stdin/stdout or to allocate memory, when
>>> compiling code.  Yes?
>>
>> No. I was thinking that the compiler would call its standard library 
>> and  that the standard library would call the OS that the compiler 
>> was  running on. The library would thus interface the compiler to the 
>> OS. The  library would be OS-specific but the compiler would not. 
>> There would be  a separate version of the library for each hosting 
>> OS.
>
> We clearly have different definitions of, or meanings, or scope for, 
> or
> boundaries for use of "dependent" here.
>
> You're just looking at the compiler's C code, which can be made 
> independent
> of the OS by simply not using the OS or C library, or calling a 
> function  not
> named in the OS or C library, but the compiler still needs to call the 
> OS  to
> do OS level work.  The compiler itself, once compiled into a binary, 
> must
> call something in the OS to allow for file I/O and memory allocation, 
> which
> makes the compiler dependent on the OS.

I am not sure what you mean by "the compiler's C code" and I may have 
misunderstood more of that paragraph (incidentally, the line endings 
seem to have come in odd places. Is that your Usenet interface or mine?) 
but I think of there being these units

  1. A compiler
  2. A standard library for Unix
  3. A standard library for DOS
  4. A standard library for MacOS
  5. A standard library for HomeBrewOS
etc

The point being that each library would provide the same functions. It's 
just that their implementations would differ. The single compiler should 
be able to interact with different operating systems by being linked 
with the appropriate library.

> E.g., if the compiler must call jh_open() in the C compiler to open a 
> file,
> which calls fopen() in the C library, which calls open() in the OS, 
> then  the
> compiler C code is technically independent of the OS.  It doesn't call 
> any  OS
> functions or C library functions directly, but does so indirectly. 
> The  compiler
> itself is actually dependent on the OS for file I/O.  If the C 
> compiler  doesn't
> call jh_open(), fopen(), open() directly or indirectly, then it's 
> independent
> in the sense that I meant.  That's impossible, AFAIK.

Yes, the compiler would ultimately have to get the OS to interact with 
the outside world. I was just saying that the compiler wouldn't itself 
have to make any calls which were specific to a certain OS. If could 
just focus on its input (source code and headers) and its output 
(assembly or machine code). I thought the standard libraries were there 
to interface the compiler or any other app to the OS. As we discussed 
elsewhere, though, it seems that the standard libraries include OS 
interfacing.

James

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-09 16:47 -0700
  Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-09 23:41 -0400
    Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 08:30 +0100
      Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-10 05:17 -0400
        Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 13:41 +0100
          Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:04 +0100
            Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 02:30 -0400
              Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-13 02:07 -0700
                Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:10 -0400
                Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-14 01:23 -0700
              Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-13 12:34 +0100
                Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 22:50 -0400
                Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-14 08:37 +0100
                Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-14 01:41 -0700
                Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-14 10:04 +0100
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:44 -0700
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 10:52 -0700
    Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:38 -0700
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 10:58 -0700
  Re: 64-bit detection CN <qmbmnp3799@pacbell.net> - 2015-07-09 23:00 -0700
    Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:40 -0700
      Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 21:29 +0100

csiph-web