English Amiga Board


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

 
 
Thread Tools
Old 03 January 2018, 17:59   #21
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,039
Quote:
Originally Posted by kamelito View Post
Hunk 000 = 72000 ($011940) Bytes
Strange, that PhxAss produced a much shorter code section. Or did you disable optimizations with vasm?

Quote:
HUNK_DATA 24624 ($006030) Bytes
HUNK_??? ($00001BE4) - Aborting!
Ok. So the hunk-structure is definitely corrupt. But both have the same size with PhxAss and vasm, although vasm used a ShortReloc Hunk:
Quote:
Originally Posted by kamelito View Post
HUNK_DATA 24624 ($006030) Bytes
HUNK_DREL32EXE
You could have prevented that with -kick1hunks. It should make both data hunks comparable.

In the hexdump I would look for the location of HUNK_DATA ($000003ea), followed by $000180c (which means $180c longworlds = $6030 bytes). Then skip $6030 bytes and look closer at that region. Also compare it with vasm's output.

If you like, you can also send me an email with the original source, so I could analyze it myself.
phx is offline  
AdSense AdSense  
Old 03 January 2018, 18:27   #22
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 874
Vasm -devpac -m68881 -Fhunkexe on top of my head
kamelito is offline  
Old 07 January 2018, 00:36   #23
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 645
Quote:
Originally Posted by kamelito View Post
Why is Link.w a5,#0 not accepted by Devpac, it says invalid size.
Only 68000. It works in 68020 settings.
Probably Devpac expects a negative immediate value.
The instruction with #0 is senseless in the meaning of the instruction. It will reserve a stackspace of length 0 bytes. It's created by compilers missing optimization.
If it works in 68020 mode just check if it creates a identical binary (or use a other assembler)
Wepl is offline  
Old 07 January 2018, 10:07   #24
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,490
The instruction with #0 isn't senseless. It still creates a frame pointer that can access parameters passed to the function. It's just that there will be no local variables.

Devpac rejects .w as link on 68000 has no size (= always word-sized).
meynaf is offline  
Old 08 January 2018, 15:36   #25
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 645
Quote:
Originally Posted by meynaf View Post
The instruction with #0 isn't senseless. It still creates a frame pointer that can access parameters passed to the function. It's just that there will be no local variables.
A7 could be used then to reference the parameters.
AFAIK only Aztec-C is creating these link an,#0 stuff.
Wepl is offline  
Old 08 January 2018, 15:39   #26
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,786
Could it just be that for instructions which can only have one size, Devpac doesn't like it when you specify the size? How does it like MOVEQ.L vs MOVEQ by comparison?
mark_k is offline  
Old 08 January 2018, 15:50   #27
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,490
Quote:
Originally Posted by Wepl View Post
A7 could be used then to reference the parameters.
AFAIK only Aztec-C is creating these link an,#0 stuff.
A7 can be used to reference local variables as well... LINK/UNLK are just a shortcut.
But things can become unwieldy if you start to push things on stack, hence the frame pointer which has a constant value during the whole routine.

Many compilers have the "omit frame pointer" optimization option, but they still emit these link #0 by default. No time to statistically study the ones that actually do, though


Quote:
Originally Posted by mark_k View Post
Could it just be that for instructions which can only have one size, Devpac doesn't like it when you specify the size? How does it like MOVEQ.L vs MOVEQ by comparison?
It looks like this indeed. MOVEQ still has no size, but LINK got one starting with 68020. Same story for CHK.
meynaf is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Vampire 500+ Pre-orders now being accepted TuKo Amiga scene 331 20 July 2017 19:00
Link external modules in Devpac Knocker Coders. Asm / Hardware 6 23 March 2016 16:22
Devpac 3.x christopherpm request.Apps 27 30 January 2015 10:50
Devpac 3 BippyM MarketPlace 11 19 July 2012 19:21
Devpac 3.x Frank Black request.Apps 13 27 August 2006 01:24

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 11:14.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.18846 seconds with 13 queries