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

[John Drake]

--- Fernando Passold <fpassold at das.ufsc.br> wrote:
> 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
> descriptor
> > 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.

Ok.  Here's a stupid question on my part.  Have
you tried the tech support contacts at XO2.org?

http://www.xo2.org/Pages/contacts.html

The newsgroup comp.lang.oberon may be helpful
also.

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

Well I don't think the PowerPC uses a segmented
memory, but then I'm just guessing here.  Doesn't
the PowerPC have a 32 bit instruction pointer?
Which PowerPC is it?  (603, 604, 740?)

Anyway at least you have something to test.  What
ideas do you have on shriking the code?  Perhaps
you can split it into two modules.
 
> 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
> code.

I've run into that on the Intel platform also.

Regards,

John M. Drake

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com