Re: C and Low-level Storage (was: I need a new compiler...

On Dec 19, 5:26 am, PR <paul.rauler...@xxxxxxxxx> wrote:
On Dec 18, 12:46 am, Richard <rip...@xxxxxxxxxxxx> wrote:



On Dec 18, 4:32 pm, Paul <paul-nospamatall.rauler...@xxxxxxx> wrote:

On 2008-12-16 22:25:13 -0600, Richard <rip...@xxxxxxxxxxxx> said:

On Dec 17, 4:41 pm, Paul <paul-nospamatall.rauler...@xxxxxxx> wrote:
On 2008-12-16 17:02:31 -0600, "William M. Klein"
<wmkl...@xxxxxxxxxxxxxxxxxxxx> said:

<much debate snipped>

Michael Wojick,
  I can't tell.  Have you been debating a "real-world" issue or a p
hilosophical
one?

In other words, are there existing implementations of C that (as requir
ed)
support "pointers" but do NOT  allow (or support) pointers that "get
the
program" to system-level storage?

I am NOT a C programmer, but when I have interacted with those that do
use it,
it seems to me that all implementations that they use DO allow the C pr
ogram to
access (at least "read") data at "system controlled" (low-level?) stora
ge.

It is also true, that some "systems" do NOT allow the "average" C (or A
ssembler
or whatever) program to MODIFY "system-controlled" storage, but that is
 a
different question (to me) than accessing such storage.

If there are C implementations that do not allow programmers to "read"
the
storage where "system control blocks, etc" reside, I would be intereste
d in
which C and on what platforms these exist.

If you are just stating that the C Standard does not REQUIRE this, then
that may
be "nice to know" - but is different from what actual implementations D
O.

If I understand what you are saying Bill, you are asking if C the
language can access "system memory."

Technically, C can access any address the machine can provide access
to, including any system storage.

Practially speaking, the Operating System, and sometimes the hardware,
protects some areas of memory. This is especially true in all our
modern systems like z/OS, Linux, z/VM, and even Windows, since
applications run in a designed application space.

For example, on my zLinux systems, every application in the system
loads and run from  address X'400000'. Of couse, that is a *virtual*
address, which means there may be a thousand applcations running from
the virtual address, but from 1000 different real addresses. It gets
complex, because sometimes text (code) sections are designated
read-only in memory, and only one copy of them is loaded. (This is
Linux,
drives z/OS programmers crazy because they cannot store variable in the
code section - at least if they ever intend to change those variable's
values... :)

And then you get into shared memory segments. Take the same chunk of
real memory, attach it to one or more applications - at different
virtual addresses.

Like I said, it gets complex. Fun though. :)

Another point to consider, most of Unix, including the kernel level
code (which by the way, usually *does* have access to every real memory
address, system and application....)  is written in plain old C. Just a
couple or three thousand lines of assembler, and the rest, millions of
lines of code, in C.

And how have you established that it is the C code (and not the
assembler) that "*does* have access to every real memory address",

Because I look at the assembler code that the C compiler generates of course.
The following code will generate an error, because memory address 100
is protected
by MacOS and UNIX.
#include <stdio.h>
int main(int argc, char *argv[]) {

  char *aCharPointer;
  char aCharVariable;

  aCharPointer = 100;
  aCharVariable = *aCharPointer;

  }

No, it is not the 'operating system' that causes the error, it is the
hardware. Your code is not attempting to access real address 100, it
is only attempting to access an address within the virtual machine
created for your program. Given that Intel is little-endian the
pointer has some segment reference that does not exist within that
virtual machine.

On a Z80 or 8086 a pointer to 0:100 would actually access the real
address 100, but that was a 30 years ago.

In protected mode the machine is _not_ a Z80 or 8086. You cannot
simply set a pointer to an arbitrary value and expect it to access
some data. Pointers are segment:offset and the only valid segments
that you can use without the hardware dumping you are the ones allowed
in your virtual machine.

In Intel (or Wintel Parlance)

        .text
.globl _main
_main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        movl    $100, -16(%ebp)
        movl    -16(%ebp), %eax
        movzbl  (%eax), %eax
        movb    %al, -9(%ebp)
        leave
        ret
        .subsections_via_symbols

Easier to see in mainframe GAS assembler I suppose:

        .file   "test.c"
.text
        .align  4
.globl main
        .type   main, @function
main:
.LFB3:
        stm     %r11,%r15,44(%r15)
.LCFI0:
        ahi     %r15,-112
.LCFI1:
        lr      %r11,%r15
.LCFI2:
        st      %r2,96(%r11)
        st      %r3,100(%r11)
        lhi     %r1,100
        st      %r1,104(%r11)
        l       %r1,104(%r11)
        mvc     108(1,%r11),0(%r1)
        lhi     %r1,0
        lr      %r2,%r1
        lm      %r11,%r15,156(%r11)
        br      %r14

The line I bolded above is the one that is doing "aCharVariable =
*aCharPointer;"
A moments study will show that R1 has the value 100 in it, so in HLASM,
it would
look like this:

LHI   R1,100
LA    R2,aCharVariable
MVI  0(R2),0(R1)

It is the same on Linux, VMS, AIX, MacOS, and so on, with varying
degrees of complexity.

By the way, MVI 0(R2),0(R1) is using indirect memory references; in
essence R1 and R2 are pointers.

or
indeed that it is the C code that puts the machine into the mode that
allows access by real memory address, sans which it cannot be done.

Whether the C code is *allowed* permission to access a particular
memory address or not has nothing to do with C, it has to do with
whether or not the Operating System will allow the running application
to do so.

No. Wrong. In protected mode it is the hardware that will prevent you
accessing arbitrary addresses. Even then these would be virtual
addresses and not the real address that you think you can get at.

Are you by some chance thinking that the hardware controls whether it
is in protected mode or not?
If so, then you need to go do some study.  It is the OS that
determines what mode, and *what addressing
mode* is used.

Certainly the OS is in control of what goes on. In many cases it is
the hardware that will do address translation and checking
permissions.The exception may well be passed back to the OS to deal
with but the OS is not usually involved with examining every CPU
cycle. (In fact that would require CPU cycles to do so, which it would
have to examine, which ...)


By the way, under Windows, that *does* access physical memory address
100. Applications are ran in a flat memory model, and an absolute
address, like the one I entered, actually does map to the same
physical address.

You are claiming that the address translation tables do not do
anything.

If the program has legitimate access to a specific address then where
that lies in physical memory is determined by the ADT. In particular
two programs accessing what they think are the same address (ie
identical bit patterns in the pointer) will access completely
different physical memory locations because they have different ADTs.

So while your code may well try to access 'absolute address 100' where
that lies in _physical_ memory depends entirely on where the page
manager has loaded it for your process and the ADT will translate that
access to that page.


The variable I defined, aCharVar, may be at *offset
zero in the data segment*, but the virutal address will be wherever
the data segement is mapped to.

Same is true under the UNIX I ran it under by the way, or I would not
have put it up as an example.

You really don't understand how an OS works do you?  I recommend you
go find an old copy of Tennnebaum's MINIX book.
It will help you understand OS processing a lot better.

And, has been pointed out before, it is the _implementation_ that
creates the code that runs in protected mode.

Code running in Kernel mode is absolutely no different from code
running in application mode; it merely has different permissions.

Actually the 'permissions' can allow special machine instructions to
be executed and, if the compiler can generate these then the code _is_
different from that running in application mode.

No it isn't. It is the same code.

It is only "the same code" if the compiler is capable of generating
that code, and that depends on the particular _implementation_.

Whether it MAY execute or not has
nothing to do with
whether it is CAN. There is a fundamental difference here you are
missing. When code is running
in kernel or privileged or level zero (or whatever the particular OS
calls its internal run state)
mode, it is absolutely no different from code running in application
state. Same ones and zeros.

There is nothing that says you cannot write those instructions into
application level code, and then run
the application level code at a higher privilege level.

You may well be able to -in-assembler- but, getting back to the actual
topic, how do you get a particular C compiler to "write those
instructions into application level code" if there is no statement
that the compiler can use to tell it that.



Indeed - what do you think system calls are?

In some systems 'system calls' are requests for the operating system
to perform some function on behalf of the user process. The system
call puts the request on one of the queues and suspends the process
(or not if it is async). The OS processes the request and then puts
the user process back to ready state so it can continue on some later
context switch.

Other systems may do it in other ways.


Of
course, kernel mode code can access all the memory in the machine it is
running on (or in the virutal machine it is running on in the case of
z/VM, VMWare, Parallels, etc.)

One of the jobs of an operating system is to manage memory...

Just out of curiousity - are there any OS's written in Cobol?
I don't know of any, but I bet there are one or two out there. :)



.

Relevant Pages

  • Re: Oracle 10g startup problem
    ... system as a virtual machine. ... my SGA has 164 MB of memory. ... I decreased my SGA size to 100MB, ... This one's a bit strange because Ana has checked everything I know I'd ...
    (comp.databases.oracle.server)
  • Re: Oracle 10g startup problem
    ... system as a virtual machine. ... my SGA has 164 MB of memory. ... I decreased my SGA size to 100MB, ... VMware Server, and on ESX Server. ...
    (comp.databases.oracle.server)
  • Re: Impact if changing the number of cpu
    ... Also in regards to your VMWARE question. ... "VMWare ESX server" you can configure your virual machine to have 1 or 2 ... Same with memory, you can adjust memory either up or ... your virtual machine needs to be shut down to make changes to the ...
    (microsoft.public.windows.server.general)
  • Re: How to speedup VPC7
    ... >>I've got a powermac 2x2,5Ghz with 4,5 Gb of internal memory. ... Dropping the RAM does nothing to performance... ... you can run a 512 MB virtual machine in Virtual PC ... > Can you provide the details of your VM, OS, did it come with VPC, etc? ...
    (microsoft.public.mac.virtualpc)
  • Re: Application memory allocation in XP Pro
    ... An older memtest program might not see memory ... allocate most of the 4GB memory space to a program. ... 3.6GB for virtual machine memory space with 2GB to any one virtual machine. ... > unallocated RAM, XP Pro would only allocate about 1475 MB of that 1.8 ...
    (microsoft.public.windowsxp.basics)