[Oberon] Please, what does it means? And how do deal with this?

Fernando Passold fpassold at das.ufsc.br
Thu Mar 27 15:46:20 CET 2003

Hello, Mr. McIntosh

    At first, thanks a lot by your truthful interest.
I'll try to deserve it.

> The intel '386 and higher processors have flags in the task selector
> that control how the CPU works.  Some of the flags denote that a segment
is a
> data or code segment.

 Well presented fundation but let me introduce somethings.

 I am making an intensive effort of programming
in Oberon System 3 - compiled on an PC but with code
to be run over a board VMEX equiped with a
PowerPC CPU running at 200(!?) MHz. This was the
framework chosen to turn an scara robot operational.
Note: It is used a PC to edit and generate te code but
the code is not running on this PC. It runs on another
kind of CPU supposed running also Oberon System 3 as
its real-time operation system. The entire system
was developed by persons of the ETH institute of
Sweden. It it supposed that today they also have
an scara robot quite equal that we have here in
Brazil. But because reforms in the ETH institute
the persons who was working with this robot have
gone out of this institution. So I am appeal to this
list lookin for a litle support.

 I need to test control algorithms including
some of them that starts trainning of artificial
neural network - knowed as to be a time consuming
algorith... The entire system was working using
conventional controllers for position control over
joint space including run also one of 2 types of
neural networks (MLP or RBF). And at this time I have
had problems as bad dimensioned arrays or have
forgotten to properly initializate arrays stated
as pointers. So, now the first thing I do when I
found run-time problems is look for this type of
variables that possible I had forgotten to properly
initializate (NEW statement).

 The problem now, more serius because I only
have more 7 days to finish my work is that
the systems sometimes comes up accusing this enigmatic
run-time mesage:

"Trap kind: Instruction-Fetch from No-Execute Segment" !?

That for me, means nothing... because I see the error
happening after statements as start real-time tasks!!!

 And yesterday, this same error occur during
the real-time task designed to initialize the robot.
It means, sincronize the relative encoders of the
robot. Detais: I ever had changed this part of code.
Neither modified parameters of this real-time task.
So, the conclusion I found is:

1) Limitations of Oberon System 3 !?
2) Limitations of the CPU running this code...

 How to discover the problem. And worst,
how to deal with this problem/limitation?

 Note the size of the codes:

26/03/2003  20:27               98.662 Robot.Mod
26/03/2003  20:27               75.494 Robot.Obx

 It appears a little big!? I am suspicious
about limitation of the compiler or CPU of the
robot. I think, maybe the compiler have generated
a code with inside jumps over than 64 Kbytes (2^16).
And the internal registers of the PowerPC can not
deal with this. It is possible as the object code today
is over than 64 Kbytes. And then the "famous" mesage
above could be justified to occur even during the
execution of part of code that ever has presented
problems. Any other hypothesis???

> If a segment is denoted as a data only segment, and a jmp, call, or rti
> attempts to send the CS:IP (program counter) to that segment, you will get
> processor exception that would be described by what you are seeing.
> In all of the Oberon systems that I have studied, the system does not
> a segment that is data only.

 I ever had  taken so deepen in the code or
Compiler options. I never have acessed data segments.
It appears as I was codifying in Assembly!!! And I have
any ideia of the internal architecture of the PowerPC.
It seems to be a RISC processor and so problably with
a large number of registers. And I remember that sometimes
the compiler has accused strange mesages for some
long statements (a long equation), something as "overflow of
intense use of registers - try to split the following
statement" or something like that. And in fact I was
forced to split these lines to continue to compile the

> I am left with the thought that the version of Oberon that you are using
> dramatically departed from all its kindred, or else you are trying to load
> task selector that was not allocated under Oberon system control.

 Maybe... The version I use today was abandoned.

Take a look:
Oberon System 3 for WindowsTM
 Win32 2.3 (25.2.1999) on Windows NT 5.0

System.ChangeDirectory D:/Oberon2001/Work
Oberon Module Interchange (OMI) / mf, tk 8.2.96
OMI reference info enabled
OMI ASSERT function enabled
TFTPd Threaded/rb, dd/ 7.4.99
XOClient v1.0.2 /rb/ 7.4.99
TextPopups using TextPopups.Text
XO/Client handler started.
TFTPd Started

> Again, I wonder about how the task was initialized that you are trying to
> Does the system use the assembler?  Do you import the module SYSTEM?
> Are you using a pointer that was never initialized and also using the
> flags that turn off the run-time checks?

 Importing the System.Obx!? May I take a look:
  ScaraRobot.Config \c

 And I do not know how indicate to the compiler for
turn off the run-time checks...  The only option that seems
it have is:

-------------- extracted from: Compiler.Tool -------------------------
The Oberon Compiler accepts the following options:

 e     Enable generation of an extended symbol file
 u Suppress compilation if object file is up-to-date
 s Enable generation of a new symbol file
 w    Enable generation of warning messages

Each filename may be followed by a slash ("\") and a list of options.

 Compiler.SetDestPath NewObj
 Compiler.Compile *\e
 Compiler.Compile Demo/Demo.Mod\e Test.Mod\s ~
 Compiler.Compile \s Test1.Mod Test2.Mod Test3.Mod ~

In addition, you can set the following options that influence the
loading of Slim Binaries:

OMI.AssertsOn enable/disable code generation for ASSERT function
OMI.AssertsOff (default: off)

OMI.ChecksOn enable/disable index checks
OMI.ChecksOff (default: on)

OMI.RefsOn enable/disable generation of detailed reference
OMI.RefsOff information (default: off)

Native Object Files

The following compiler options are only valid in connection with the \N
option that causes the compiler to generate native object files. Note
that these files are not portable accross machine boundaries. You should
therefore only use these options when writing a driver that makes use of
the low-level module SYSTEM or the built-in SIZE function.

 N enable generation of native object file
 a suppress code generation for ASSERT function
 f find text position matching the selected PC= value
  in a TRAP
 p suppress initialization of local pointers to NIL
 t disable type checks
 v     enable overflow checks
 x disable index checks

 I ever use "XCompiler.Compile * \Nnf" to compile my programs as:

 RBF.Mod \Nns
 Sliding.Mod \Nns
 Force.Mod \Nns
 RBFTool.Mod \Nns

Ttha generates mesages like that:

XO/2 PowerPC Cross-Compiler, running on Intel /rb/ Q1 2000 / rev4c
  Oberon Portable Compiler / nw & rc
  PowerPC Code Generator  / MB, tk 7.8.95
  Mutator and Fixes  / rb 23.2.00
  compiling  Robot    51420       72


> Does this mean that you have changed some data and now the program does
> trap in the same place?

 I think so before... But now this error occurs
on other place of the code...

> Again, are you writing directly to memory using something such as
> bypassing the safety of the language?

 No. I do not know how to make this.

> Do you have a "hard deadline" scheduler version of Oberon?
> Where did you get it?

 In fact I need to run the controller algorithms every
1 milisecond. And guarantee the sampling time because sometimes
I run control algorithms with coeficients wich depends of
the sampling time period. Also a digital filter for the force sensor
as the original signal came with much noise...

 I use staments like that (extracted of Robot.Mod, one
with this error):

(* Start the Feedback Control real-time task *)
(* handler, duration, deadline, period *)
robot.controlFBTask := Tasks.NewPeriodic(robot.controlFBHdl, 200,
robot.controlFBTask.Start; (* <--- Trap kind error:
* Instruction-Fetch from No-Execute Segment !?  *)

  samplingTimeFB = 0.001; (* Feedback control sampling time *)

 I will try to shrink the object code to less than 64 Kbyte
if it is possible.. Maybe this is the only solution.

thanks very much about any feedback,

Fernando Passold

More information about the Oberon mailing list