Forum > Other OS

Assembling 68k

<< < (2/2)

PascalDragon:

--- Quote from: polluks on April 26, 2020, 02:59:28 pm ---Hi!
How do you support a bigger displacement?
error 2030 in line 140338 of "T:27B5522mp.s": displacement out of range
>       mulu.l  -70768(%a5),%d0

--- End quote ---

Is it Pascal code or inline assembler that leads to this? Can you provide a full, small, self contained example that demonstrates this? What did you set the processor to (option -CpXXX)?

TRon:
Sorry as i am not TS.

I am able to reproduce using RC1 cross so am able to answer some of the questions.


--- Quote from: PascalDragon on April 27, 2020, 09:37:33 am ---Is it Pascal code or inline assembler that leads to this?

--- End quote ---
Although I have not checked all the code/includes, it seems to be Pascal.


--- Quote ---Can you provide a full, small, self contained example that demonstrates this?

--- End quote ---
Unfortunately not (yet).

(Somewhat large) project that is able to reproduce can be found at https://github.com/tebe6502/Mad-Pascal , where i downloaded release 1.6.3


--- Quote ---What did you set the processor to (option -CpXXX)?

--- End quote ---
-CP option does not seem to matter at all.

I have also tried to cross-compile to MorphOS (also vasm, version 1.8h) which led to:

--- Code: ---Free Pascal Compiler version 3.2.0rc1 [2020/04/28] for powerpc
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: MorphOS
Compiling mp.pas
mp.pas(349,51) Note: Values in enumeration types have to be ascending
mp.pas(20092,16) Note: Local variable "AllocElementType" is assigned but never used
mp.pas(20093,5) Note: Local variable "NumAllocElements" is assigned but never used
mp.pas(24178,5) Note: Local variable "NumAllocElements" is assigned but never used
mp.pas(24467,33) Note: Local variable "ParamIndex" not used
mp.pas(24467,45) Note: Local variable "idx" not used
mp.pas(29834,3) Note: Local variable "NumAllocTypes" not used
Assembling madpascal
Linking mp
Fatal error 1: Out of memory.
Aborting.
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: ppcrossppc returned an error exitcode

--- End code ---

@TS. Were you able  to use the native compiler for the MOS release ?

TRon:
I'm a bit stuck.

Having a closer look at the code I can see that it primarily consist out of basic Pascal functions.

Some nested, some forwarded but that is about the most exiting bit in there. Only sysutils is used, and things are written for mode objfpc.

Turning on overflow checking will get a bit further, but then the linker bails out again.


--- Code: ---$ fpc -V3.2.0 -B -MOBJFPC -Co -Pm68k -Tamiga -XV -AVasm mp.pas -FD/home/ron/bin/binutils
Free Pascal Compiler version 3.2.0rc1 [2020/04/30] for m68k
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Commodore Amiga
Compiling mp.pas
mp.pas(357,51) Note: Values in enumeration types have to be ascending
mp.pas(20100,16) Note: Local variable "AllocElementType" is assigned but never used
mp.pas(20101,5) Note: Local variable "NumAllocElements" is assigned but never used
mp.pas(24186,5) Note: Local variable "NumAllocElements" is assigned but never used
mp.pas(24475,33) Note: Local variable "ParamIndex" not used
mp.pas(24475,45) Note: Local variable "idx" not used
mp.pas(29842,3) Note: Local variable "NumAllocTypes" not used
Assembling madpascal
Linking mp
Fatal error 1: Out of memory.
Aborting.
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /home/ron/bin/fpc/3.2.0/bin/arm-linux/ppcross68k returned an error exitcode

--- End code ---

I have run a couple of other tests against this setup and those seem to work ok so far (although I haven't actually tested the resulting execs from those tests)

Is there anything else I can try with my limited knowledge on the asm/linker backend ?

TRon:
After a consult with ALB42, i realised that i had overlooked something and that is the fact that the code makes heavy use of static arrays. And those are simply too big (for the specific target).

FPC produces code for it, but it is simply too much for the back-end to chew on.

Converting some of those static arrays into dynamic ones then the code starts to compile without errors.

That leaves the question if there should be a more meaningful error and if such situation occurs that FPC should even produce ('faulty') code for it to being with.

Right now I am unsure whether it is FPC or the asm/linker which is 'at fault' so that i don't even know if it would be helpful to submit a bugreport.

Navigation

[0] Message Index

[*] Previous page

Go to full version