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

On Dec 19, 4:35 pm, Paul <paul-nospamatall.rauler...@xxxxxxx> wrote:
On 2008-12-18 21:12:25 -0600, Richard <rip...@xxxxxxxxxxxx> said:



On Dec 19, 3:30 pm, Paul <paul-nospamatall.rauler...@xxxxxxx> wrote:
On 2008-12-18 13:03:40 -0600, Richard <rip...@xxxxxxxxxxxx> said:

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> wro
te:
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 th
at do
use it,
it seems to me that all implementations that they use DO allow th
e 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 t
hat 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 int
ereste
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 implementat
ions 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 acce
ss
to, including any system storage.

Practially speaking, the Operating System, and sometimes the hardw
are,
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 *virt
ual*
address, which means there may be a thousand applcations running f
rom
the virtual address, but from 1000 different real addresses. It ge
ts
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 i
n the
code section - at least if they ever intend to change those variab
le'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 leve
l
code (which by the way, usually *does* have access to every real m
emory
address, system and application....)  is written in plain old C.
 Just a
couple or three thousand lines of assembler, and the rest, million
s 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 o
f
 course.
The following code will generate an error, because memory address 10
0
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 allowe
d
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 HLA
S
M,
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 th
at
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 applicati
o
n
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 ...)

If it quacks like a duck and it acts like a duck - it ain't no armidillo.

Are you saying that an OS can magically run without a CPU or the ancillar
y
chips that make up a computer?

I don't think that is what you mean of course, but that is the logical
equivalent
of what you are saying.

In what way is your nonsense 'equivalent' ? How do you derive this
from what I said ?

Your claim was that the OS will prevent access to specific addresses.
While the OS may well set up the address translation table it is the
hardware (CPU + MMU) that will actually prevent an illegal access.

The only nonsense here is what you are sprouting.

I claimed the OS will prevent access to specific addresses and it will. The
CPU and MMU did not just magically set themselves up, as you seem to be
claiming.

You think computers run without software or something?

When the program attempts to execute an instruction that accesses an
arbitrary address, say, address 100 then on a real mode machine the
access will occur, on a protected mode machine where this address is
not allowed then it is the hardware (eg CPU/MMU/..) that detects that
the access is invalid.

The OS is not looking at every memory access made by the program and
determining whether it is allowed or not, the hardware is.

While the OS does create the ADT which forms the basis of what is
_allowed_ it is the hardware that uses these to detect when an access
is _outside_ those allowed and will prevent this.




Of course we assume that an OS runs on a computer,
and uses the facilities of said computer, be it CPU, MMU, or whatever els
e,
with some effect.

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.

...

read more »

.

Relevant Pages

  • Re: High memory
    ... memory and then copy it up above 1MB...but if you want to put ... outside the CPU, memory is seen in a completely different light...this ... 1MB with "real mode memory" labelled on it or anything...the actual memory ... the system bus to actual hardware devices...hence, ...
    (alt.lang.asm)
  • Re: How to develop a random number generation device
    ... single shared CPU; much less, in fact, since irrevelant interrupts, ... probably through shared memory and semaphores. ... switches are a reliability issue - processors don't have problems with them. ... If you shift the complexity to hardware, you'd get hardware that is expensive and buggy. ...
    (sci.electronics.design)
  • Re: What Linux distro to use for old Intel machine, that fits on CDs?
    ... CPU: Pentium 3, 933 MHz ... Memory: 512MB ... Considering the uncertainty of what hardware you have, ... path of getting a USB flash based system to boot on ancient hardware. ...
    (comp.os.linux.misc)
  • Re: Fresh install wont compile requirement libraries for cvsup
    ... I'd tend to suspect memory rather than cpu. ... touch with much of the hardware that was out there. ... I'd treat it to a new heat sink with fresh thermal paste and a BIG fan. ...
    (freebsd-questions)
  • Re: "Mastering C Pointers"....
    ... each of which have more than one processor and memory space. ... The XBox uses an Intel ... x86-type CPU as its main driver; the GameCube has a PowerPC CPU; ... pointer to a byte pointer, the compiler must shift it left, ...
    (comp.lang.c)