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
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
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.
? 2012?12?15????UTC
+8??7?57?48??David Brown ??le
s.
i know, in my experience, instructions out of user level instruction set ca n 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, dir ectly related with a bit in cpu's mode register. but does this has any rela tionship with compiler to decide how to translate c code to assembler codes ?
? 2012?12?15????UTC
+8??7?57?48??David Brown ??le
s.
i know, in my experience, instructions out of user level instruction set ca n 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, dir ectly related with a bit in cpu's mode register. but does this has any rela tionship with compiler to decide how to translate c code to assembler codes ?
not be
mode
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:
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.
(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.)
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).
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
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!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.