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

Groups > alt.os.development > #8355

Re: 64-bit detection

Show all headers | View raw

"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:

...

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

Sounds like stress city! Not that we should all approach these things in 
the same way but you may have noticed that I often try to *reduce* some 
of these discussions by closing down points and not asking questions. 
That way, the correspondent isn't prompted to respond if he doesn't want 
to and that subthread can just die a natural death. If you are 
overloaded by posts to respond to perhaps you could reply but also offer 
to reduce the content. When you ask lots of questions and bring up new 
subpoints the threads can increase in size.

>> 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 stack size check is a good example. That is something that I may come 
back to one day in a separate thread when I've got a bit more time or 
really need it.

In the context of this discussion perhaps such a check could be included 
only as and when needed, by use of a compiler switch. Then the 
compiler's output does not have to be environment specific.

> a privilege level check, an OS stack allocation routine,

I don't agree about those as I don't think it's the compiler's job to 
automatically insert them. If the programmer wants such things (and they 
are permitted!) then he or she can code them. In the quest for portable 
apps I don't think I would even want apps to do either of those things.

> or a call trace routine in the prolog.

Again, maybe a compiler switch would insert this if the user requires it 
so that the default code would be independent of the intended execution 
environment.

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

IMO compilers should not call anything other than what they are told to. 
I don't yet know how feasible that is but it seems a good maxim.

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

Memory allocation functions can be in a standard library rather than in 
the compiler.

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

I think x86 flag DF is sometimes defined by the calling convention. A 
bad idea, IMO, but it would be good if compilers allowed the calling 
convention to be specified, at least for calls to external functions 
which might have been written in another language.

> Obviously, host specific code is needed for main() and C-runtime.

Yes, but neither of those is emitted by the compiler so the compiler 
should be able to remain independent of the host-specific requirements, 
IMO.

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

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

Yes. At least the emitted code shouldn't be dependent on the things you 
mention. It should just be executable code. I suppose the linker can 
carry out various gyrations to get the code to fit in the available 
memory but not the compiler.

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

Sure. Things may be done that way. I am just saying that that seems to 
me a bad idea and unnecessary.

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

Oh, you mean the generated code including software interrupt 
instructions? I didn't guess that. I agree that the compiler should not 
emit such instructions. If it needs services that are invoked by such 
instructions on certain OSes then the emitted code should call a library 
function which issues the software interrupt. That keeps the compiler's 
output clean and maybe allows the library function to be replaced with 
one for a different OS.

Further, the compiler's output probably should not call any library 
functions which the programmer has not asked it to.

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

Yuck! Bad compiler! ..... :-(

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

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

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

OK.

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

OK.

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

OK.

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.

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

Yes, that may be true. I don't know for sure, yet. Best guess at this 
time is that C's flexibility may rescue me from what a compiler expects. 
I don't mean to be cryptic but this is something to come back to.

...

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

>> What would it take for a compiler to be independent of the hosting 
>> OS?
>
> Did you mean "compiler proper" or "compiler emitted code" here? ...

Both. The next two points in my post (which I think you have snipped) 
covered one each.

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

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

That seems to be a good list but as I am unsure what you mean it is 
probably best that I don't guess. I may have covered some of your points 
in what I wrote above.

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