Assembling 68k

[polluks]

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

Thanks,
Stefan

[TRon]

How do you support a bigger displacement?

You don't ?.

It is a limitation of the processor, e.g. afaik displacement on a 68k can be 16 bit max.

Are you addressing custom (f.e. fpga) hardware that offers such support ?

[polluks]

Thanks for your quick reply
The 68020 offers 32-bit displacement
https://books.google.de/books?id=eVcEWDIeTYcC&pg=PA332&lpg=PA332&dq=32-bit+displacement&source=bl&ots=kzktXlrZgr&sig=ACfU3U2vWwsCkgtgc2STL47ji8LNWeRI_g&hl=de&sa=X&ved=2ahUKEwiPiqPTtIbpAhWRiqQKHTN0D4YQ6AEwAHoECAYQAQ#v=onepage&q=32-bit%20displacement&f=false

By the way I'm counting thee errors

Code: Text  [Select][+][-]

1. Free Pascal Compiler version 3.2.0-beta [2019/12/14] for m68k
2. Copyright (c) 1993-2018 by Florian Klaempfl and others
3. Target OS: Commodore Amiga
4. Compiling mp.pas
5. mp.pas(346,51) Note: Values in enumeration types have to be ascending
6. mp.pas(1227,15) Warning: Local variable "best" of a managed type does not seem to be initialized
7. mp.pas(1349,12) Warning: Local variable "l" of a managed type does not seem to be initialized
8. mp.pas(2553,21) Warning: Local variable "stackBuf" of a managed type does not seem to be initialized
9. mp.pas(19627,16) Note: Local variable "AllocElementType" is assigned but never used
10. mp.pas(19628,5) Note: Local variable "NumAllocElements" is assigned but never used
11. mp.pas(23719,5) Note: Local variable "NumAllocElements" is assigned but never used
12. mp.pas(23953,22) Note: Local variable "AllocElementType" is assigned but never used
13. mp.pas(26701,29) Warning: Local variable "CaseLabelArray" of a managed type does not seem to be initialized
14. mp.pas(29733,21) Warning: Local variable "UnitList" of a managed type does not seem to be initialized
15. mp.pas(29262,3) Note: Local variable "NumAllocTypes" not used
16. Assembling madpascal
17.  
18. error 2030 in line 167386 of "T:2035BC7mp.s": displacement out of range
19. >       mulu.l  -70804(%a5),%d0
20.  
21. error 2030 in line 167403 of "T:2035BC7mp.s": displacement out of range
22. >       mulu.l  -70804(%a5),%d0
23.  
24. error 2030 in line 169829 of "T:2035BC7mp.s": displacement out of range
25. >       mulu.l  -70804(%a5),%d0
26. FreePascal:bin/m68k-amiga/vasmm68k_std fehlgeschlagen Rückgabewert 20
27. Error: Error while assembling exitcode 20
28. Fatal: There were 2 errors compiling module, stopping
29. Fatal: Compilation aborted

[marcov]

That's a message of the assembler, so which assembler do you use?

FPC generates it, so it probably generates code for 68020 or higher.

[TRon]

Thanks for your quick reply

You're more than welcome :-)

The 68020 offers 32-bit displacement

Sorry, I still interpret the text differently.

That link writes that it is a 16 bit displacement which is extended to 32 bit before doing the actual math.

The motorola user manual has a table that writes:
Addressing mode, Register indirect, Address with Displacement, Syntax: (d16, An)

Which version of vasm are you using, as i have not encountered it it myself (just) yet. I have still to test fpc 3.2.0 rc1

@marcov: that is vasm: http://sun.hasenbraten.de/vasm/

If it is fpc generating the code then i do believe there could be something amiss ?

PS @polluks
Unfortunately  getting sources legitimate is a bit tricky. Try a search for the M68020 user manual (UM) (Motorola/NXP/freescale doesn't matter, any will do). Additionally you could download the datasheet for the 020 as well (you can find the table I referenced there as well) or try the M68000 Programmer's Manual (PRM) and take a peek here: https://www.cs.mcgill.ca/~cs573/fall2002/notes/lec273/lecture10/ where the motorola 'tech' syntax is more or less translated into actual asm instructions that you're probably more familiar with.

Feel free to correct me in case i'm wrong.

[PascalDragon]

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

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.

Is it Pascal code or inline assembler that leads to this?

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

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

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

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

-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: [Select]

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

@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: [Select]

$ 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

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.