>
> "David Brown" <david.brown@removethis.hesbynett.no> wrote:
>
>> It is not that privileged instructions /cannot/ be emitted by the
>> compiler - just that they normally /will/ not be emitted. There is no
>> reason for them to be emitted, as such instructions do not correspond to
>> anything in the C language. So you would only see them as a result of
>> explicit use of intrinsics or builtins, or via inline assembly.
>
> There are few special cases when compiler could issue system instructions on
> its own. That is disabling interrupts when accessing volatile objects, or
> avoiding specific bugs of the CPU, or something like that.
>
That's certainly true - there is nothing that stops a compiler doing
that, except that no one would want a compiler that issued privileged
instructions without an explicit request in the source code. For
processors that support user-supervisor privilege separation, there
should never be a need for supervisor-level instructions - for example,
they will have user-level instructions to handle things like atomic
accesses. For processors that don't have such support, there is no real
harm in issuing special instructions - though it would be rare to do so.
The only case I can think of is that msp430 gcc disables interrupts
around access to the hardware multiplier, but I am sure it is not alone.
Of course, in embedded development there are /always/ exceptions - there
is bound to be /some/ processor out there that requires supervisor-level
instructions to implement volatile accesses!
Reply by Vladimir Vassilevsky●December 17, 20122012-12-17
> It is not that privileged instructions /cannot/ be emitted by the
> compiler - just that they normally /will/ not be emitted. There is no
> reason for them to be emitted, as such instructions do not correspond to
> anything in the C language. So you would only see them as a result of
> explicit use of intrinsics or builtins, or via inline assembly.
There are few special cases when compiler could issue system instructions on
its own. That is disabling interrupts when accessing volatile objects, or
avoiding specific bugs of the CPU, or something like that.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
(I don't know what Usenet client you are using, but it does a truly
crappy job of quoting and formatting - if you are able to switch to a
better client, it will make your posts nicer for the rest of us.)
>>
>> But regarding the original question about privileged instructions,
>> I
>>
>> would be surprised if any of these were emitted by the compiler -
>> except
>>
>> possibly from code that explicitly requested them from intrinsic
>> functions.
>
> i know, in my experience, instructions out of user level instruction
> set can not be emited directly by compiler from c codes. i want to
> know is there any theory evidence or something describe this
> explicitly? i think user privilege or system privilege, it mean some
> states of cpu, directly related with a bit in cpu's mode register.
> but does this has any relationship with compiler to decide how to
> translate c code to assembler codes?
>
It is not that privileged instructions /cannot/ be emitted by the
compiler - just that they normally /will/ not be emitted. There is no
reason for them to be emitted, as such instructions do not correspond to
anything in the C language. So you would only see them as a result of
explicit use of intrinsics or builtins, or via inline assembly.
Usually any mode register control that is useful at a user level is
accessible at a user level. For example, there may be a register
controlling things like floating point rounding modes. That sort of
mode register will be accessible at user level, and it may well be that
the compiler will make use of it in instructions it emits (though
usually that would be restricted to a single setting as part of the C
startup code, or controlled by compiler directives, pragmas or intrinsic
functions).
Reply by Robert Wessel●December 17, 20122012-12-17
On Mon, 17 Dec 2012 06:32:06 -0800 (PST), alvin
<alvin.yangrs@gmail.com> wrote:
>? 2012?12?15????UTC+8??7?57?48??David Brown???
>> On 13/12/12 18:45, Tim Wescott wrote:
>>
>> > On Thu, 13 Dec 2012 08:54:43 -0800, alvin wrote:
>>
>> >
>>
>> >> for example, for powerpc, has user level instruction set and system
>>
>> >> level instruction set. when we compile c codes, how gcc decide to use
>>
>> >> which instrution set.
>>
>> >>
>>
>> >> like mbar or sync, these instruction only be used when we write assemble
>>
>> >> language in codes, or gcc can decide to use them itself base on
>>
>> >> optimization or compile options?
>>
>> >
>>
>> > At least in my experience, none of the system level instructions are
>>
>> > needed to do the things that C is intended to do.
>>
>> >
>>
>> > In more formal terms, none of those instructions are needed to support
>>
>> > the C virtual machine.
>>
>> >
>>
>> > It's not the job of the C compiler to support computer functions beyond
>>
>> > the C virtual machine -- that's the job of the operating system, or in
>>
>> > the absence of one, the system programmer.
>>
>> >
>>
>> > IOW, it's what assembly language programming is for.
>>
>> >
>>
>>
>>
>> While that is mostly the case, there are situations where a compiler
>>
>> might emit special instructions (though it is very unlikely that it
>>
>> would use privileged instructions). For example, to implement volatile
>>
>> accesses on some architectures, or the atomic accesses from the latest
>>
>> standards, it could make use of instructions such as the aforementioned
>>
>> "mbar" and "sync" - or even manipulating interrupt enables. gcc for the
>>
>> msp430 has a "critical" function attribute that will disable interrupts
>>
>> around the function contents, and it will disable interrupts around the
>>
>> use of the hardware multiplier. For some targets the compiler may emit
>>
>> cache manipulation instructions (in particular, prefetch requests) which
>>
>> might be considered "system instructions".
>>
>>
>>
>> And of course many commonly needed assembly codes (such as for interrupt
>>
>> enables and disables) will be available as builtins or compiler
>>
>> intrinsics - or at least as functions in the toolchain's standard
>>
>> libraries. Whether you consider that as library code or
>>
>> compiler-generated code is sometimes a grey area.
>>
>>
>>
>> Also, the specific question was regarding gcc, which is more than just a
>>
>> C compiler. Compilation for Ada will probably include a certain number
>>
>> of "system" instructions to handle multi-threading support.
>>
>>
>>
>> But regarding the original question about privileged instructions, I
>>
>> would be surprised if any of these were emitted by the compiler - except
>>
>> possibly from code that explicitly requested them from intrinsic functions.
>
>i know, in my experience, instructions out of user level instruction set can not be
>emited directly by compiler from c codes. i want to know is there any theory
>vidence or something describe this explicitly? i think user privilege or system
>privilege, it mean some states of cpu, directly related with a bit in cpu's mode
>register. but does this has any relationship with compiler to decide how to
>translate c code to assembler codes?
The compiler writers decide what instructions the compiler can emit.
In the case of GCC, the front ends generate an (approximately) CPU
independent form of RTL. Somewhat simplified, there's a "machine
description" file that's part of the back end, which contains the
rules for translating the RTL into assembler. This include
conditional bits which allows different machine models to be supported
(IOW, what you specify with the "-march" parameter). This is mostly
done as a set of interacting rules and patterns that that GCC uses to
do that translation. There are rules for all sorts of things from
jump optimizations to looping to...
Note that there is nothing inherent in any of that preventing someone
from emitting privileged instructions.
Doing a simple, and unoptimized GCC back end is not that complex for a
reasonably simple CPU (at least for someone already familiar with both
the CPU and the rather complex rules for a GCC backend), but a good
one is great deal of work.
Also defined there are various compiler intrinsics which provide
access to various CPU features that don't match what you can do in
"normal" code in a program translated by a front end. For example,
the __builtin_ia32_paddb() intrinsic exposes the PADDB x86 MMX
instruction.
Now GCC is not big on supporting privileged intrinsics (they have
strong in-line assembler support, which is used to cover most of
that), but there's nothing other than policy actually preventing them
from defining such. Some non-mainline GCC implementations (for
example those in some of the embedded toolchains) have such.
OTOH, the MSVC folks prefer to not do as much inline assembler (in
fact the x86-64 MSVC compiler dropped all support for inline
assembler), and they provide many privileged instruction intrinsics.
For example, on x86 platforms, MSVC provides the __invlpg() intrinsic,
which generates the obvious privileged x86 instruction.
There would be no reason a compiler couldn't generate a privileged
instruction for ordinary code (presumable based on a -march, or
similar, option), but most privileged instructions on CPUs don't
really lend themselves to that sort of thing. For example, there is
simply no reason to ever emit an INVPAG x86 instruction as part of
ordinary C code. Most privileged instructions are like that.
And there's nothing at the compiler level preventing it from
generating an instruction that you cannot use, either because the
actual target you're running on doesn't support it, or the mode you're
in doesn't allow it. Although you probably won't get the results you
want when you try to run the program (in most cases you'll get an
abend instead).
While not simple, you can get more information about the GCC back end
here:
http://gcc.gnu.org/onlinedocs/gccint/Back-End.html
Other compilers, with less cross platform ambitions, often have their
code generation much more scattered throughout the compiler itself,
unlike the fairly well centralized approach taken by GCC.
> On 13/12/12 18:45, Tim Wescott wrote:
>
> > On Thu, 13 Dec 2012 08:54:43 -0800, alvin wrote:
>
> >
>
> >> for example, for powerpc, has user level instruction set and system
>
> >> level instruction set. when we compile c codes, how gcc decide to use
>
> >> which instrution set.
>
> >>
>
> >> like mbar or sync, these instruction only be used when we write assemble
>
> >> language in codes, or gcc can decide to use them itself base on
>
> >> optimization or compile options?
>
> >
>
> > At least in my experience, none of the system level instructions are
>
> > needed to do the things that C is intended to do.
>
> >
>
> > In more formal terms, none of those instructions are needed to support
>
> > the C virtual machine.
>
> >
>
> > It's not the job of the C compiler to support computer functions beyond
>
> > the C virtual machine -- that's the job of the operating system, or in
>
> > the absence of one, the system programmer.
>
> >
>
> > IOW, it's what assembly language programming is for.
>
> >
>
>
>
> While that is mostly the case, there are situations where a compiler
>
> might emit special instructions (though it is very unlikely that it
>
> would use privileged instructions). For example, to implement volatile
>
> accesses on some architectures, or the atomic accesses from the latest
>
> standards, it could make use of instructions such as the aforementioned
>
> "mbar" and "sync" - or even manipulating interrupt enables. gcc for the
>
> msp430 has a "critical" function attribute that will disable interrupts
>
> around the function contents, and it will disable interrupts around the
>
> use of the hardware multiplier. For some targets the compiler may emit
>
> cache manipulation instructions (in particular, prefetch requests) which
>
> might be considered "system instructions".
>
>
>
> And of course many commonly needed assembly codes (such as for interrupt
>
> enables and disables) will be available as builtins or compiler
>
> intrinsics - or at least as functions in the toolchain's standard
>
> libraries. Whether you consider that as library code or
>
> compiler-generated code is sometimes a grey area.
>
>
>
> Also, the specific question was regarding gcc, which is more than just a
>
> C compiler. Compilation for Ada will probably include a certain number
>
> of "system" instructions to handle multi-threading support.
>
>
>
> But regarding the original question about privileged instructions, I
>
> would be surprised if any of these were emitted by the compiler - except
>
> possibly from code that explicitly requested them from intrinsic functions.
i know, in my experience, instructions out of user level instruction set can not be emited directly by compiler from c codes. i want to know is there any theory evidence or something describe this explicitly?
i think user privilege or system privilege, it mean some states of cpu, directly related with a bit in cpu's mode register. but does this has any relationship with compiler to decide how to translate c code to assembler codes?
> On 13/12/12 18:45, Tim Wescott wrote:
>
> > On Thu, 13 Dec 2012 08:54:43 -0800, alvin wrote:
>
> >
>
> >> for example, for powerpc, has user level instruction set and system
>
> >> level instruction set. when we compile c codes, how gcc decide to use
>
> >> which instrution set.
>
> >>
>
> >> like mbar or sync, these instruction only be used when we write assemble
>
> >> language in codes, or gcc can decide to use them itself base on
>
> >> optimization or compile options?
>
> >
>
> > At least in my experience, none of the system level instructions are
>
> > needed to do the things that C is intended to do.
>
> >
>
> > In more formal terms, none of those instructions are needed to support
>
> > the C virtual machine.
>
> >
>
> > It's not the job of the C compiler to support computer functions beyond
>
> > the C virtual machine -- that's the job of the operating system, or in
>
> > the absence of one, the system programmer.
>
> >
>
> > IOW, it's what assembly language programming is for.
>
> >
>
>
>
> While that is mostly the case, there are situations where a compiler
>
> might emit special instructions (though it is very unlikely that it
>
> would use privileged instructions). For example, to implement volatile
>
> accesses on some architectures, or the atomic accesses from the latest
>
> standards, it could make use of instructions such as the aforementioned
>
> "mbar" and "sync" - or even manipulating interrupt enables. gcc for the
>
> msp430 has a "critical" function attribute that will disable interrupts
>
> around the function contents, and it will disable interrupts around the
>
> use of the hardware multiplier. For some targets the compiler may emit
>
> cache manipulation instructions (in particular, prefetch requests) which
>
> might be considered "system instructions".
>
>
>
> And of course many commonly needed assembly codes (such as for interrupt
>
> enables and disables) will be available as builtins or compiler
>
> intrinsics - or at least as functions in the toolchain's standard
>
> libraries. Whether you consider that as library code or
>
> compiler-generated code is sometimes a grey area.
>
>
>
> Also, the specific question was regarding gcc, which is more than just a
>
> C compiler. Compilation for Ada will probably include a certain number
>
> of "system" instructions to handle multi-threading support.
>
>
>
> But regarding the original question about privileged instructions, I
>
> would be surprised if any of these were emitted by the compiler - except
>
> possibly from code that explicitly requested them from intrinsic functions.
i know, in my experience, instructions out of user level instruction set can not be emited directly by compiler from c codes. i want to know is there any theory evidence or something describe this explicitly?
i think user privilege or system privilege, it mean some states of cpu, directly related with a bit in cpu's mode register. but does this has any relationship with compiler to decide how to translate c code to assembler codes?
Reply by David Brown●December 14, 20122012-12-14
On 13/12/12 18:45, Tim Wescott wrote:
> On Thu, 13 Dec 2012 08:54:43 -0800, alvin wrote:
>
>> for example, for powerpc, has user level instruction set and system
>> level instruction set. when we compile c codes, how gcc decide to use
>> which instrution set.
>>
>> like mbar or sync, these instruction only be used when we write assemble
>> language in codes, or gcc can decide to use them itself base on
>> optimization or compile options?
>
> At least in my experience, none of the system level instructions are
> needed to do the things that C is intended to do.
>
> In more formal terms, none of those instructions are needed to support
> the C virtual machine.
>
> It's not the job of the C compiler to support computer functions beyond
> the C virtual machine -- that's the job of the operating system, or in
> the absence of one, the system programmer.
>
> IOW, it's what assembly language programming is for.
>
While that is mostly the case, there are situations where a compiler
might emit special instructions (though it is very unlikely that it
would use privileged instructions). For example, to implement volatile
accesses on some architectures, or the atomic accesses from the latest
standards, it could make use of instructions such as the aforementioned
"mbar" and "sync" - or even manipulating interrupt enables. gcc for the
msp430 has a "critical" function attribute that will disable interrupts
around the function contents, and it will disable interrupts around the
use of the hardware multiplier. For some targets the compiler may emit
cache manipulation instructions (in particular, prefetch requests) which
might be considered "system instructions".
And of course many commonly needed assembly codes (such as for interrupt
enables and disables) will be available as builtins or compiler
intrinsics - or at least as functions in the toolchain's standard
libraries. Whether you consider that as library code or
compiler-generated code is sometimes a grey area.
Also, the specific question was regarding gcc, which is more than just a
C compiler. Compilation for Ada will probably include a certain number
of "system" instructions to handle multi-threading support.
But regarding the original question about privileged instructions, I
would be surprised if any of these were emitted by the compiler - except
possibly from code that explicitly requested them from intrinsic functions.
Reply by Vladimir Vassilevsky●December 13, 20122012-12-13
"alvin" <alvin.yangrs@gmail.com> wrote in message
news:c640d45a-0825-4c43-b238-64f9c7295609@googlegroups.com...
> for example, for powerpc, has user level instruction set and system level
> instruction set. when we compile c codes, how gcc decide to use which
> instrution set.
>
> like mbar or sync, these instruction only be used when we write assemble
> language in codes,
> or gcc can decide to use them itself base on optimization or compile
> options?
Compiler never emits system instructions by itself. You can use system
instructions by calling system library functions or by assembly code.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
.
Reply by Tim Wescott●December 13, 20122012-12-13
On Thu, 13 Dec 2012 08:54:43 -0800, alvin wrote:
> for example, for powerpc, has user level instruction set and system
> level instruction set. when we compile c codes, how gcc decide to use
> which instrution set.
>
> like mbar or sync, these instruction only be used when we write assemble
> language in codes, or gcc can decide to use them itself base on
> optimization or compile options?
At least in my experience, none of the system level instructions are
needed to do the things that C is intended to do.
In more formal terms, none of those instructions are needed to support
the C virtual machine.
It's not the job of the C compiler to support computer functions beyond
the C virtual machine -- that's the job of the operating system, or in
the absence of one, the system programmer.
IOW, it's what assembly language programming is for.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply by alvin●December 13, 20122012-12-13
for example, for powerpc, has user level instruction set and system level instruction set. when we compile c codes, how gcc decide to use which instrution set.
like mbar or sync, these instruction only be used when we write assemble language in codes, or gcc can decide to use them itself base on optimization or compile options?