Re: [fpc-devel] Messages overhead

Hans-Peter Diettrich schrieb: > Daniël Mantione schrieb: > >>> IMO compiler messages slow down compilation a lot. >> >> How do you know this, did you benchmark or is it just your opinion? > > Common knowledge, proved by experience. Please profile the compiler first, people did this already. > T

Re: [fpc-devel] Messages overhead

Hans-Peter Diettrich wrote: Daniël Mantione schrieb: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? Common knowledge, proved by experience. I had benchmarked that, and submitted some patching some (already long) time

Re: [fpc-devel] Parser rewrite

Marco van de Voort schrieb: Will it do harm when I create more than one branch, e.g. one for general optimizations? Can other people contribute to such an branch as well? Keep in mind that running many branches long term will only increase the amount of management to keep them in sync, makes i

Re: [fpc-devel] Re: Compiler bottlenecks

Jonas Maebe schrieb: Apart from specific scenarios, memory mapping can easily be slower than direct reads. The main reason is that you get round trips to the OS via hardware interrupts whenever you trigger a page fault, instead of doing one or more (relatively cheap compared to interrupts) sys

Re: [fpc-devel] Messages overhead

Daniël Mantione schrieb: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? Common knowledge, proved by experience. [...] Sounds reasonable to me, but wether it will speed up compilation is another question. Anyway, simply

Re[2]: [fpc-devel] Purpose of "uses ... in"?

Hello Mattias, Wednesday, July 14, 2010, 7:05:01 PM, you wrote: >> And now, you understood the little problem? MG> Of course I understand the problem, but I have not yet encountered MG> it in a real project. I can vaguely remember a case like this in Delphi several years ago, but I think the pro

Re: [fpc-devel] Purpose of "uses ... in"?

Marcos Douglas schrieb: > On Wed, Jul 14, 2010 at 2:55 PM, Stefan Kisdaroczi wrote: >> create a rar.pas containing only the line: >> {$include rar/zip.pas} >> >> compile with: >> fpc -Un rar.pas >> >> -UnDo not check where the unit name matches the file name > > Interesting... > Anyone

Re: [fpc-devel] Purpose of "uses ... in"?

Hi! On 14.07.2010 15:36, Adem wrote: Is there, still, a platform (where FPC can be used) that restricts filenames to being so short? FPC still supports DOS, which only supports 8.3 filenames, if I'm informed correctly. (Can someone comment on FreeDOS regarding this?) Regards, Sven _

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 3:22 PM, Marco van de Voort wrote: > In our previous episode, Marcos Douglas said: >> > sure that that all filenames are unique. This because there are still two >> > uses clauses will cause problems. >> >> You're right :( >> And if we can do that: >> uses >>   zip IN '/uni

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 2:55 PM, Stefan Kisdaroczi wrote: > > create a rar.pas containing only the line: >  {$include rar/zip.pas} > > compile with: >  fpc -Un rar.pas > > -Un        Do not check where the unit name matches the file name Interesting... Anyone ever used this? MD. ___

Re: [fpc-devel] Purpose of "uses ... in"?

In our previous episode, Marcos Douglas said: > > sure that that all filenames are unique. This because there are still two > > uses clauses will cause problems. > > You're right :( > And if we can do that: > uses > zip IN '/units/my/zip.pas' AS myzip; > zip IN '/units/lib/zip/zip.pas' AS zipl

Re: [fpc-devel] Purpose of "uses ... in"?

On 14.07.2010 18:54, Marcos Douglas wrote: > On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner > wrote: > >> On Wed, 14 Jul 2010 12:51:29 -0300 >> Marcos Douglas wrote: >> >> >>> On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner >>> wrote: >>> On Wed, 14 Jul 2010 12:23:00 -

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 2:21 PM, Marco van de Voort wrote: > In our previous episode, Marcos Douglas said: >> > And if they want to keep it, then I can not use both Dialogs units. I >> > had not yet the case where I needed both and can not rename both. >> >> Then, another example: >> You want to w

Re: [fpc-devel] Purpose of "uses ... in"?

In our previous episode, Marcos Douglas said: > >> And now, you understood the little problem? > > > > Of course I understand the problem, but I have not yet encountered > > it in a real project. > > So, if we can to put an alias to unit names, there are no more problem. > I had this problem in re

Re: [fpc-devel] Purpose of "uses ... in"?

In our previous episode, Marcos Douglas said: > > And if they want to keep it, then I can not use both Dialogs units. I > > had not yet the case where I needed both and can not rename both. > > Then, another example: > You want to work with ZIP and RAR format files. So, imagine you found, > on the

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > I don't think we ever going to give an up front carte blanche for a massive > > rewrite to go into trunk. That is simply not sane. > > ACK. I'm more concerned about work that is blacklisted for some reason. One reason the more to phase and m

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 2:05 PM, Mattias Gaertner wrote: > On Wed, 14 Jul 2010 13:54:10 -0300 > Marcos Douglas wrote: > >>[...] >> > I would tell the devels of the framework. >> > And if they want to keep it, then I can not use both Dialogs units. I >> > had not yet the case where I needed both a

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, 14 Jul 2010 13:54:10 -0300 Marcos Douglas wrote: >[...] > > I would tell the devels of the framework. > > And if they want to keep it, then I can not use both Dialogs units. I > > had not yet the case where I needed both and can not rename both. > > Then, another example: > You want to w

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner wrote: > On Wed, 14 Jul 2010 12:51:29 -0300 > Marcos Douglas wrote: > >> On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner >> wrote: >> > On Wed, 14 Jul 2010 12:23:00 -0300 >> > Marcos Douglas wrote: >> > >> >> On Wed, Jul 14, 2010 at 11:45 AM

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Nikolai Zhubr wrote on Wed, 14 Jul 2010: 14.07.2010 15:44, Hans-Peter Diettrich: [...] Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them. Oh come on, the user who insert asm instuctions manually doesn't nee

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

14.07.2010 15:44, Hans-Peter Diettrich: [...] Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them. Oh come on, the user who insert asm instuctions manually doesn't need such a naive 'protection'. I'm pretty sure

Re: [fpc-devel] arm embedded cortexm3 procedure address

Geoffrey Barton wrote on Wed, 14 Jul 2010: the resulting constant disassembles as:- 1bc:01a5.word 0x01a5 which seems to be one greater than the address of the procedure. Is this right? Yes. If so, why? To identify the code as Thumb code. also, why does the compiler

[fpc-devel] arm embedded cortexm3 procedure address

disassembling from an elf file produce by FPC cross-assembling for arm embedded, an empty procedure:- procedure UART0int:nostackframe; begin end; looks like this:- 01a4 : 1a4: 46f7mov pc, lr 1a6: 46c0nop (mov r8, r8) if I grab the ad

Re: [fpc-devel] Re: Compiler bottlenecks

On 2010-07-14 18:21, Jonas Maebe wrote: Apart from specific scenarios, memory mapping can easily be slower than direct reads. The main reason is that you get round trips to the OS via hardware interrupts whenever you trigger a page fault, instead of doing one or more (relatively cheap compared

Re: [fpc-devel] Compiler bottlenecks]

Jonas Maebe schrieb: This technique is well known and implemented by virtually all memory managers these days (it's called pooling, or freelists). FPC's default memory manager also does that (up to a certain allocation size). Unless you create huge pools, it does not affect total memory much.

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: I don't think we ever going to give an up front carte blanche for a massive rewrite to go into trunk. That is simply not sane. ACK. I'm more concerned about work that is blacklisted for some reason. A subsmission will always be judged on performance and maintainab

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, 14 Jul 2010 12:51:29 -0300 Marcos Douglas wrote: > On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner > wrote: > > On Wed, 14 Jul 2010 12:23:00 -0300 > > Marcos Douglas wrote: > > > >> On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner > >> wrote: > >> > On Wed, 14 Jul 2010 10:26:11 -0

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner wrote: > On Wed, 14 Jul 2010 12:23:00 -0300 > Marcos Douglas wrote: > >> On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner >> wrote: >> > On Wed, 14 Jul 2010 10:26:11 -0300 >> > Marcos Douglas wrote: >>[...] >> >> I am surprised as there is no

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, 14 Jul 2010 12:23:00 -0300 Marcos Douglas wrote: > On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner > wrote: > > On Wed, 14 Jul 2010 10:26:11 -0300 > > Marcos Douglas wrote: >[...] > >> I am surprised as there is no conflict of names of units in the FPC / > >> Lazarus. > > > > Of cou

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner wrote: > On Wed, 14 Jul 2010 10:26:11 -0300 > Marcos Douglas wrote: > >> On Wed, Jul 14, 2010 at 10:03 AM, Hans-Peter Diettrich >> wrote: >> > Thaddy schrieb: >> > >> >> Programmers are not very imaginative in naming. It is plainly helpfull to >

[fpc-devel] Re: Compiler bottlenecks

Hans-Peter Diettrich wrote on Wed, 14 Jul 2010: Marco van de Voort schrieb: Mapping does not change that picture (the head still has to move if you access a previously unread block). Mapping mainly is more about - zero-copy access to file content - and uses the VM system to cache _already a

Re: [fpc-devel] Messages overhead

Op Wed, 14 Jul 2010, schreef Hans-Peter Diettrich: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? When messages are not really output (prevented by message level...), then a lot of procedure calls and string operations

[fpc-devel] Messages overhead

IMO compiler messages slow down compilation a lot. When messages are not really output (prevented by message level...), then a lot of procedure calls and string operations can be avoided, when the message preparation is bypassed at all. verbose.Message1 ff. could check the level (and exit acco

Re: [fpc-devel] Compiler bottlenecks]

Adem wrote on Wed, 14 Jul 2010: On 2010-07-14 13:29, Thaddy wrote: The one thing that caught my eye that might or might not be reason to worry is this: "Memory Usage Part of the speedup that TopMemory achieves comes from allocating more memory then necessary and grouping allocations that

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, 14 Jul 2010 10:26:11 -0300 Marcos Douglas wrote: > On Wed, Jul 14, 2010 at 10:03 AM, Hans-Peter Diettrich > wrote: > > Thaddy schrieb: > > > >> Programmers are not very imaginative in naming. It is plainly helpfull to > >> be able to rename a file if another file with a different content

Re: [fpc-devel] Purpose of "uses ... in"?

2010/7/14 Adem : >  On 2010-07-14 16:26, Marcos Douglas wrote: >> >> I am surprised as there is no conflict of names of units in the FPC / >> Lazarus. >> There are names very short, which could be used as variable names... > > Is there, still, a platform (where FPC can be used) that restricts filen

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > And Delphi (Windows!) users reported noticeable performance boosts > (factor 3+), even if nobody ever came up with non-trivial example code, > including fallbacks for restricted (32 bit) address space. Yeah, and no wonder, most probably be

Re: [fpc-devel] Compiler bottlenecks]

On 2010-07-14 13:29, Thaddy wrote: The link is for a very good scaling memorymanager over multi processor systems provided the software is also well written. Ivo's memorymanager is even lock free, if you use it properly. I hadn't heard about TopMemory till now. I read the PDF that comes in t

Re: [fpc-devel] Blackfin support

In our previous episode, Hans-Peter Diettrich said: > > > > Probably if you go linearly, the readahead is already near efficient. > > Windows offers certain file attributes for that purpose, that notify the > OS of intended (strictly) sequential file reads - what would allow to > read-ahead mor

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Hans-Peter Diettrich wrote: Bernd Mueller schrieb: Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. In this case I don't understand how FPC is useful at all. I cannot create executable files

Re: [fpc-devel] Purpose of "uses ... in"?

On 2010-07-14 16:26, Marcos Douglas wrote: I am surprised as there is no conflict of names of units in the FPC / Lazarus. There are names very short, which could be used as variable names... Is there, still, a platform (where FPC can be used) that restricts filenames to being so short? Cheer

Re: [fpc-devel] Compiler bottlenecks]

Hans-Peter Diettrich schrieb: > Thaddy schrieb: >> Hans-Peter Diettrich wrote: >>> >>> Memory management can not normally be parallelized. >>> >> What's this then: http://topsoftwaresite.nl/ You are talking cows dung. >> It is actually in production at one of the largest stockbrokers in >> Europe.

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 10:03 AM, Hans-Peter Diettrich wrote: > Thaddy schrieb: > >> Programmers are not very imaginative in naming. It is plainly helpfull to >> be able to rename a file if another file with a different content. > > Just in the FPC compiler case many unit names are hard coded,

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Hans-Peter Diettrich schrieb: > Bernd Mueller schrieb: > >> Users, who do embedded stuff (without OS) NEED FULL control over the >> controller. I agree with Jeppe, that the compiler should not restrict >> something. > > In this case I don't understand how FPC is useful at all. I cannot > create e

Re: [fpc-devel] Compiler bottlenecks]

Thaddy schrieb: Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. It is actually in production at one of the largest stockbrokers in Europe. You should have written : "It is hard to do parall

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. How that? Of course

Re: [fpc-devel] Purpose of "uses ... in"?

Thaddy schrieb: Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. Just in the FPC compiler case many unit names are hard coded, while the files to use reside e.g. in a specific machine directory, se

Re: [fpc-devel] Blackfin support

Marco van de Voort schrieb: In our previous episode, Michael Schnell said: On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK F

Re: [fpc-devel] Blackfin support

Michael Schnell schrieb: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. I've hear

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Bernd Mueller schrieb: Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. In this case I don't understand how FPC is useful at all. I cannot create executable files for such a device... Oth

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

On 14/07/10 11:54, Nataraj S Narayan wrote: Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? Do you still need this with the latest fpc compiled for eabi? Henry ___ fpc-devel maillist - fpc-devel@li

Re: [off list] Re: [fpc-devel] Compiler bottlenecks]

On 14/07/10 12:46, Thaddy wrote: A fact has nothing to do with emotions. Check that code. Then write a review. I presume he was talking about the cow's dung. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman

Re: [off list] Re: [fpc-devel] Compiler bottlenecks]

A fact has nothing to do with emotions. Check that code. Then write a review. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

[off list] Re: [fpc-devel] Compiler bottlenecks]

Thaddy wrote on Wed, 14 Jul 2010: Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. Please try not to add emotionally laden terms like that to your posts. Thanks, Jonas FPC mailing list

Re: [fpc-devel] Purpose of "uses ... in"?

On Wed, Jul 14, 2010 at 7:49 AM, Marco van de Voort wrote: > In our previous episode, Thaddy said: >> > >> Yes, but that defeats unit aliasing by renaming: like "uses foo in >> "bar.pas"" instead of "uses foo" (implies "in foo.pas"). Did somebody >> mention this in the discussion? > >> Programmers

Re: [fpc-devel] Purpose of "uses ... in"?

Marco van de Voort wrote: In our previous episode, Thaddy said: Ok, you write always cheerful, I was merely pointing out it is not clean, but useful :)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailma

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Nataraj S Narayan wrote: Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? The fpc target for eabi is called 'armel', the 'arm' target compiles for oabi. Regards, Micha On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Could it be because FPC uses OABI per default? :) Try recompiling fpc and your application for EABI. I'm not an expert on ABI's, though as far as I understand, it's merely a definition of how userland applications should call Linux kernel functions Nataraj S Narayan skrev: Hi May I ask why d

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? regards Nataraj On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen wrote: > Well, this is off topic, but ARM is quite a bit backwards compatible. All > ARM versions are backwards compatible(if we ig

Re: [fpc-devel] Purpose of "uses ... in"?

In our previous episode, Thaddy said: > > > Yes, but that defeats unit aliasing by renaming: like "uses foo in > "bar.pas"" instead of "uses foo" (implies "in foo.pas"). Did somebody > mention this in the discussion? > Programmers are not very imaginative in naming. It is plainly helpfull >

Re: [fpc-devel] Purpose of "uses ... in"?

Michael Schnell wrote: On 07/13/2010 06:27 PM, Jonas Maebe wrote: b) indeed also because of the searching for filenames with different cases. It might sometimes indeed make sens to not be forced to use the same name for the unit and the file containing it's source code. So using "in" with ju

Re: [fpc-devel] Compiler bottlenecks]

Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. It is actually in production at one of the largest stockbrokers in Europe. You should have written : "It is hard to do parallization" The lin

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Well, this is off topic, but ARM is quite a bit backwards compatible. All ARM versions are backwards compatible(if we ignore thumb, which fpc doesn't support anyway) :) Geoffrey Barton skrev: On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bern

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using "DC" ???) that is not the point. You don't wont to bother with (

Re: [fpc-devel] Blackfin support

In our previous episode, Michael Schnell said: > On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: > > One of these issues are memory mapped files, that can speed up file > > access a lot (I've been told), perhaps because it maps directly to the > > system file cache? > AFAIK File Mapping is

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using "DC" ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the r

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using "DC" ???) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freep

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

On 07/13/2010 05:38 PM, Hans-Peter Diettrich wrote: I don't know details about this CPU, but possibly priviledged operations (and registers) are not part of the CPU definition, because these cannot be used in ordinary applications. It may be a good idea to create multiple code generators, f

Re: [fpc-devel] Blackfin support

On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ avail

Re: [fpc-devel] Blackfin support

On 07/13/2010 05:19 PM, Hans-Peter Diettrich wrote: It may be a good idea to implement different models, that either read entire files... "read" -> "map" -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/

Re: [fpc-devel] Blackfin support

On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. In fact I suppose using file mapping instead o

Re: [fpc-devel] Purpose of "uses ... in"?

On 07/13/2010 06:27 PM, Jonas Maebe wrote: b) indeed also because of the searching for filenames with different cases. It might sometimes indeed make sens to not be forced to use the same name for the unit and the file containing it's source code. So using "in" with just a file name, without

Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode

Hans-Peter Diettrich wrote: Jeppe Johansen schrieb: I think that'll only complicate things. I think the compiler should be able to do anything, down to lowest level. Just like you have CLI, HLT, FXSTOR, WRMSR, etc instruction support in x86 Then many users will wonder why their application wi