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

Groups > alt.os.development > #8350

Re: 64-bit detection

Show all headers | View raw

On Sun, 12 Jul 2015 14:04:51 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

>> Hosted C compilers emit code for a specific host OS, specific
>> processor mode, specific memory set up such as paging or
>> segmented or flat, interrupt method, position independent code
>> or not, static or dynamic linked code, C run-time, etc.
>
> You raise some very interesting points. I haven't, until recently, had  
> to consider such things and I have been deciding on a few application  
> memory layouts (and checking that there are ways to get an *existing*  
> build chain to use them). That has delayed my responses to you in the  
> "How to bind HLLs to OS calls" thread. I have two of your posts there to  
> get back to once I have worked something out. I think I am nearly there.  
> I can, at least, make a comment or two here on the points you mentioned  
> above.

I've over a dozen of yours, plus most of yours over the past week, and
basically all of Alexei's ...

> RP: Hosted C compilers emitting code for:
>
> RP: specific host OS.
>
> If you mean the hosting of the generated code then IMO the compiler  
> should not generate *any* OS-dependent code. It should be able to do  
> that as long as the source code doesn't make any calls specific to a  
> certain OS, shouldn't it?

It depends on the host OS.

AIR, C compilers for certain OSes call a host OS function in the prolog
of each function.  E.g., perhaps a C compiler calls a stack size check,
a privilege level check, an OS stack allocation routine, or a call trace
routine in the prolog.  If there is a stack allocation routine in the
prolog, there might be a free routine in the epilog too.  It's possible
that a C compiler for DOS which is independent of DOS calls BIOS in
compiled code ...  If it does, it'd be OS-independent.  AIR, C++ compilers
call the "new" and "delete" operators behind the scenes in the compiled
C++ code, i.e., you'd need to implement those memory allocation functions.
You can't say that the expected state of DFflag is not OS-dependent.
E.g., if your OS expects DF to be set, but the host compiler clears DF.
Obviously, host specific code is needed for main() and C-runtime.

> 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 ...
Obviously, you'd prefer a 32-bit compiler that emitted code for ring-0,
code/data segments 4GB, flat memory, etc.

> RP: a specific memory setup such as paging or segmented or flat.
>
> So far I intend all apps just to use a flat memory. Perhaps it is odd  
> that anything else was ever considered. Exposing the underlying  
> different segmentation models so directly to apps was always a bad idea,  
> IMO. I can explain that further if you wish but don't want to bore you.  
> Suffice to say that when all apps use flat memory (or think they are  
> using flat memory) the issues don't arise.

Yes, but, again, if you use a hosted C compiler, you don't get to decide
how that is set up.  E.g., if you use a Windows C compiler that used
segmented memory setup, your OS has to implement that same model to use
that code.

> RP: interrupt method.
>
> I am not sure what you mean there but you may be referring to writing  
> interrupt-handling code in C. I do that but use assembly to set up a  
> suitable environment first. (To be clear, the assembly you saw before  
> had two parts: 1. Receive the interrupt and save CPU state which was the  
> bulk of the code, 2. set up the environment ready for HLL calls, which  
> was small.)

The C compiler shouldn't generate code for the C language which calls
interrupts as you're not calling the C library or the OS, but it might.
If the C code when compiled generates an interrupt, then it'll emit
instructions specific to that OS, e.g., Int 21h for DOS vs. Int 80h
for Linux or perhaps a BIOS call.  Some C compilers for just the
C language, not C libraries, aren't 100% clean.

> 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 memory below 1MB is hard
mapped and accessed via special functions.  So, you can load a DJGPP
app to physical address 1MB or 2MB or whatever and you can execute it
there, and you can load multiple apps.  OpenWatcom apps aren't relative
like this.  They're coded for a specific address.  It has to be loaded
to that address to be executed.  So, if you want multiple OW apps to
load and execute, you're out of luck.  You can adjust the base address
of the segment to allow app to execute where loaded, but if it attempts
to access low memory, e.g., screen, the addresses will be wrong.
Basically, you'd need a way to use paging to map all loaded OW apps to
the same address.  I don't believe that can be done.

> RP: statically or dynamically linked code.
>
> I would want to allow programmers to use the OS as they wish but my  
> preference is to have apps distributed as folders of object modules. As  
> such, the OS itself would link them so all such linking would appear to  
> be dynamic but could use static mechanisms. I am not sure whether that  
> covers what you meant, though.

If you intend to use dynamically linked apps, but the compiler uses
statically linked, you'll need a compiler option to select.  If that's
not available, you're out of luck.  You're stuck with whatever model
the compiler uses.

> RP: C run time.
>
> Possibly a particular compiler's C run time can be avoided by 1) not  
> having a C main function and 2) not invoking any features from the C  
> run-time code...?

...

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

> What would it take for a compiler to be independent of the hosting OS?

Did you mean "compiler proper" or "compiler emitted code" here? ...

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?

So, I'm thinking you meant emitted code:

0) be able to compile code for multiple processors
1) be able to emit code for different memory models than the OS uses
2) be able to emit code for processor modes other than what the OS uses
3) be able to emit code which doesn't use any OS data structures
4) be able to remove all calls to the OS especially prolog/epilog and C  
language
5) be able to remove all calls to the C libraries  (much can be  
independent ...)
6) not be C++ due to "new" and "delete" memory allocation
7) not use an OS call or memory allocation call to set up a parameter stack
8) not accept parameters or provide a return from main()
9) be able to select register or stack calling convention
10) be able to change parameter convention, e.g., stdcall, cdecl, pascal,  
etc.
...

Basically, it would need to be able to do two things to be independent
*enough* for you to use, not necessarily 100% independent:

1) do what the host OS needs
2) do what your OS needs
3) you don't need to care about anything else or any other OS

ISTM, that you really need a full featured C compiler, perhaps GCC.


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