English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 13 May 2018, 23:28   #1
roger_bratseth
Rascal/Cartel

 
Join Date: May 2018
Location: Sorumsand / Norway
Age: 46
Posts: 5
Roll eyes (sarcastic) Devpac: Data section in Chip-Mem

This is my first post, so bear with me...

My Devpac3 documenation suggests that I can get data-sections loaded in Chip-mem with this assembler directive before the data:

SECTION Image,DATA_C


But how is this supposed to work in practice? The code is relocatable, and is loaded somewhere in Fast-Mem, $200000-somewhere on my system. In my code I'm referencing relative symbols, how am I supposed to reach the data if the AmigaDOS-loader puts a section/hunk somewhere in Chip-Mem?

My workaround now is to allocate chip-mem and move the data at runtime.

Any thoughts or input around this?

Kind regards,
R. Bratseth
roger_bratseth is offline  
Old 13 May 2018, 23:41   #2
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,235
Hi and welcome.

There are two methods.
- advanced: scan through hunks list in memory
- standard an simple that use reloc in executable: reference through a label

For the latter one example is:

Code:
SECTION Code,CODE
Start: lea my_image,a0
       ...
       rts

SECTION Image,DATA_C
my_image: ds.b 320*256/8
ross is online now  
Old 13 May 2018, 23:49   #3
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 7,018
Quote:
Originally Posted by roger_bratseth View Post
This is my first post, so bear with me...

My Devpac3 documenation suggests that I can get data-sections loaded in Chip-mem with this assembler directive before the data:

SECTION Image,DATA_C


But how is this supposed to work in practice? The code is relocatable, and is loaded somewhere in Fast-Mem, $200000-somewhere on my system. In my code I'm referencing relative symbols, how am I supposed to reach the data if the AmigaDOS-loader puts a section/hunk somewhere in Chip-Mem?

My workaround now is to allocate chip-mem and move the data at runtime.

Any thoughts or input around this?

Kind regards,
R. Bratseth
Because of the potential distance between sections, and the fact you're using sections, you won't be able to use PC relative code to reference data in other areas of memory.

You will have to use absolute addresses, which will relocate to the correct address when the program is run.

If you wish to keep your code PC relative and use pointers, that keeps your code neat.

So for instance

move.l picture_pointer(pc),a0

picture_pointer: dc.l picture

Section Picture,Data_C
Picture: incbin sysicture.raw

But most will settle for simply using absolute which will relocate.

lea picture,a0
Galahad/FLT is offline  
Old 14 May 2018, 00:12   #4
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,235
Just to add some info about "indirect" access suggested by Galahad (that I make it also fall into the second of my cases).

You might ask why use a slower code (four more cycles, [EDIT:in pure 68k]), which requires 2 bytes more in code section and that in any case uses a relocation.
Well, to maintain open a possibility for a change of "picture_pointer" in successive code. You can take the first setup like an init.

If you think you never change the pointer then use the lea statement.

Last edited by ross; 14 May 2018 at 00:20. Reason: []
ross is online now  
Old 14 May 2018, 02:13   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
Quote:
Originally Posted by Galahad/FLT View Post
Because of the potential distance between sections, and the fact you're using sections, you won't be able to use PC relative code to reference data in other areas of memory.
Nearly unknown to most people is that OS3.0 introduced a new relocation hunk called HUNK_RELRELOC32, which in fact enables resolving relative references between sections! It only works with 32-bit PC-relative references though, so a 68020 is required, additionally to V39.
phx is offline  
Old 14 May 2018, 09:45   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,238
Personnally I value the BASEREG directive very much. Ok, it doesn't work on Devpac
meynaf is offline  
Old 14 May 2018, 11:06   #7
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,235
Quote:
Originally Posted by phx View Post
Nearly unknown to most people is that OS3.0 introduced a new relocation hunk called HUNK_RELRELOC32, which in fact enables resolving relative references between sections! It only works with 32-bit PC-relative references though, so a 68020 is required, additionally to V39.
Never interested (but I had seen him in the list of available) at this hunk.
Can be useful to make more compact 020+ code (freeing some structured data).
Thank you for highlighting its existence

Quote:
Originally Posted by meynaf View Post
Personnally I value the BASEREG directive very much. Ok, it doesn't work on Devpac
Yes, BASEREG register usage are really valuable and a good practice! (I've always used it "manually" in Devpac for the heap).
ross is online now  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
HELP - Need mask for chip Mem Sinphaltimus support.Hardware 6 20 July 2017 23:38
Devpac - CNOP in a BSS Section h0ffman Coders. Asm / Hardware 30 19 March 2015 00:12
A600 2 Mb Chip Mem Upgrade (clockport) mikele MarketPlace 7 12 March 2013 08:36
Amiga 500 chip mem Nikolaj_sofus support.Hardware 3 03 September 2010 22:34
Need virtual memory for chip mem. Thorham request.Apps 7 28 March 2008 16:06

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.06680 seconds with 13 queries