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

Groups > alt.os.development > #8360

Re: 64-bit detection

Show all headers | View raw

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.

>>> 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.  E.g., addresses are dependent on base address
of the segment in the descriptor.  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.

>>> 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.

>> but memory below 1MB is hard
>> mapped and accessed via special functions.
>
> Can you not simply ask for a pointer to the memory you want, as in the  
> following?
>
>   x = malloc(....)  /* Point to some generally-usable space */
>   y = vgamem_base()  /* Point to some special memory */
>
> I don't know if I would use exactly that last name but you get the idea.  
> After each call the pointer would be what was needed and the compiler  
> would not have to emit any special code which was dependent on the  
> architecture of the machine it was running on.

DJGPP has a constant or a macro that you can either add or subtract,
appropriately, to a pointer to obtain the actual address.  However,
their use requires that zero page protection be disabled, i.e., due
to address wrap.

> From some of the things you have descibed over the years ISTM that the  
> compilers you chose to use were a big benefit - at least initially - in  
> that they did a lot to help, but that after a while their helpfulness  
> has become a burden in that they had quirks and limitations, and  
> adjusting to those caused a big lock-in to those specific compilers. I  
> guess it would be hard now to convert the code you have to assembly and  
> a portable pure-C form that could work on, say, gcc or any another  
> standard C compiler.

I always already locked-in, wanting to execute apps for DJGPP.
But, yes, working around code for an OS other than my own is not
advantageous.  It works on GCC for DOS (DJGPP).  It's not "portable
pure-C" form OS.  Issues with bugs in OW's C library was what prompted
me to halt my OS project and begin working on my own tools.  In hindsight,
I probably could've just cut OW code out, continuing with DJGPP's GCC,
but OW warns on a few things GCC misses.

>>> In the other thread we spoke about OS calls. The mechanism used in  
>>> that  to make OS calls should work on any compiler and *not* use any  
>>> compiler  dependencies so maybe that is an example of avoiding the  
>>> OS-dependencies  built in to a compiler.
>>
>> Ok.  But, does any existing hosted compiler already implement that?
>> (IIRC, no ...)
>
> No offense intended but I could see that I hadn't explained it well  
> enough and you had some misunderstandings over what I proposed. I need  
> to revisit that thread but the key point here is that the mechanism I  
> proposed did not require anything special of the compiler and should  
> thus work on any C compiler. It only used pointers, structs and function  
> calls. Nothing more. All standard C stuff, completely portable, not  
> dependent on a particular C compiler, and not requiring the compiler to  
> emit anything that the programmer had not written.

Oh, sorry, that mechanism, ok, yes.

>> 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.

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.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

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