I wrote a procedure to turn on interrupts:-

procedure intenable;nostackframe;
begin
   asm
      cpsie i
   end;
end;

The compilation fails with 'Error: Unrecognized opcode cpsie'

The compiler also does not recognise 'cpsid' and also 'primask' as in 'mrs r0,primask'

any ideas/workarounds?

Geoffrey

Add the missing instructions to the bottom of armins.dat, run mkarmins in the same directory. (and then submit patch) :-)

Geoffrey Barton wrote

I wrote a procedure to turn on interrupts:-

Are you doing a project without an OS ?

-Michael

yes, trying to :-) It is an embedded LM3S9B92 controller.

Geoffrey

Jeppe Johansen wrote

Add the missing instructions to the bottom of armins.dat, run mkarmins in the same directory.

It now recognises the mnemonic 'cpsie' but not the following 'i'.

The 'msr' instruction should also allow the interrupts to be enabled/ disabled as

msr primask,r0

but msr gives an unknown identifier error for 'primask' and all the other 'special' register names ('apsr' etc.) Perhaps they have been given different names, but I cannot find them listed anywhere in the FPC source.

(and then submit patch) :-)

well, once I have some code which works on the chip, I will ask someone where to put it :-)

Geoffrey

The bit names are a bit hard, since there aren't any parsing facilities in place for them, to my knowledge. I think they would need a special syntax to not be seen as symbols by the assembler reader

It'll take some work on the assembler reader and writer to get those special instructions to work

The special registers should be added to armreg.dat(and then run mkarmreg). I didn't add all the cortex registers. Is primask a real register btw? It just assembles to cpsr

ok, I have done that, 'msr primask,r0' compiles ok. I will disassemble and compare with the C code examples, if I can understand them :-)

Is primask a real register btw? It just assembles to cpsr

cpsr should not exist in cortexm3 according to ARM (see www.arm.com/files/pdf/Cortex-M3_programming_for_ARM7_developers.pdf eg. page 10 ) It is not in either the v7m archictecture or cortex_m3 tech ref manuals.

primask is a (real as far as I can see) one bit register. I will try flipping it on the hardware debugger and see if it changes anywhere else...

rgds
Geoffrey

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, for machines that can be used either for non-priviledged (application) or privileged (system, driver...) coding. At least a priviledge level should be passed to the compiler and assembler, so that it can flag the need for privileged instructions in the given source code.

Dodi

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

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 with included ASM from somewhere else (DOS time...) will compile fine, but fails to run :-(

DoDi

Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. Otherwise, you would need eventually ugly workarounds like the following (on ARM7 with an old fpc 2.3.1), which could easily be done in gcc btw.

procedure Disable;
{
mrs r0, cpsr
orr r0, r0, #0x80
msr cpsr, r0
}
begin
asm
.long 0xE10F0000
.long 0xE3800080
.long 0xE129F000

    end;

end;

Regards, Bernd.

If necessary, you can always code the very unusual instructions manually to hex code and provide them as DC in the ASM code.

-Michael

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

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 regular assembler mnemonics.

Regards, Bernd.

quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware!

rgds,
Geoffrey

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) :)

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

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 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

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 cannot create executable files for such a device...

Otherwise, you would need eventually ugly workarounds like

the following (on ARM7 with an old fpc 2.3.1), which could easily be done in gcc btw.

C has some language constructs for OS or driver implementation, e.g. "interrupt". Should we add these to the OPL, to make FPC/OPL compete with gcc/C? It would be nice, though, to have an Pascal DDK for Windows ;-)

Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them.

DoDi

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

LD for such targets can create .hex files, those can be loaded into such devices. I used FPC already for a control application with an LPC2124 without any OS.

sure, fpc can. I have a custom designed board running with an ARM9 (on Linux) and an ARM7 (no OS) which were both programmed in fpc. I only had to use gcc for the kernel modules.

Regards, Bernd.

Nikolai Zhubr wrote on Wed, 14 Jul 2010:

If a patch is submitted to add these opcodes, it will be applied.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

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 no-one would like such 'care'. Its almost like saying: the ordinary user might try to do i := 1; j := 0; k := i div j; and therefore generally most of integer arithmetic should also be restricted etc etc.

Nikolai