![]() |
![]() |
#61 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,758
|
The 68000 CPU supports this by opcode $303800BD. All 68000-only, and all 680x0 Assemblers must support this. This is the real reason, not that it's an odd address, or that you're reading instead of writing, or that you're moving directly instead of lea $bd.w,a0;move.w (a0),d0. If it warns you, it might (I say might) help you. If it doesn't finish Assembling a program with a valid opcode, I say it's not the Assembler you want.
|
![]() |
![]() |
#62 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,859
|
Quote:
In kamelito's example the coder made the mistake of forgetting to put a # in front of the number used in a dfb loop count. Their assembler (apparently) silently accepted this, resulting in a nasty bug in the executable. The chances of wanting to load a word from an odd address on the 68000 is very small. The only valid reason for doing it is to induce an exception. IMO it is better for the assembler to treat it as an error. On 68020+ it should warn, and have an option to error out (preferably set by default). |
|
![]() |
![]() |
#63 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
I also spent some thoughts on this topic while developing vasm, and I'm with Photon. There should be no reason for the assembler to artificially restrict the developer, even if the code is probably stupid in most cases. As long as it is valid, you should be able to generate it.
In vasm I even allowed unaligned data and instructions, if you really want that (instructions only with an option). You may have a reason for it. And such errors with odd addressing are easily spotted with an Alignment Exception. They don't cause hard to find bugs. Quote:
Although I would allow them too. You can't check everything, anyway. For example when branching to an external symbol. An odd addend (label+1) may be legal, when the (unknown) destination label is also at an odd address. Quote:
I would turn that into a warning. There may be reasons for data at an odd address. Maybe you want to copy the data somewhere else, before using it, or it is a data structure in an external format you want to replicate. For example DWARF uses words at odd addresses. |
||
![]() |
![]() |
#64 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
I agree with Photon and phx, any valid 680x0 opcodes have to be accepted by the assembler. If the assembler issues an error when it detects "stupid" opcodes, I'd immediately switch to another assembler. It's not the job of the assembler to decide if code is useful or not.
|
![]() |
![]() |
#65 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,859
|
Quote:
I also curse compilers that generate code my assembler can't reproduce. What does vasm do with a 'negative' immediate byte value - does it extend it to a word or make the upper byte 0? |
|
![]() |
![]() |
#66 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Quote:
Which means move.b #-1,d0and move.b #$ff,d0will both be encoded as $103c $00ff. I know there were a few assemblers which extended the sign into the undefined part of the word, and I added a compatibility flag in the IRA reassembler for those. But this thread is about AsmPro and I hope it does the same. ![]() |
|
![]() |
![]() |
#67 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,758
|
Even if a sizecoder would like to use the high byte e.g. for 'storage', and would like only a warning if the immediate value doesn't fit in a byte, it wouldn't affect execution.
To code in Assembler is to care about every CPU instruction - if you structure you're code well and are not under pressure for speed or size - not every single one of them. ![]() To use a higher-level language is to trust the compiler dev's knowledge of Assembler. (I hear some compilers are written in their own language as some kind of misguided test, but that obviously means the compiler generated unoptimized and generic code.) My view is that since Assembler is what we use instead of direct opcodes, in theory all opcodes supported by the CPU (definition: does not trigger Illegal Instruction by the CPU) should be supported by the Assembler. Once that is covered, niceties can be added, but it's important to still avoid things we've seen like sub An->suba, dbf->dbra, "moveq.b" etc. If it makes sense, I want to know that the price I pay and the reward for writing every CPU instruction is that what I write is translated exactly. ![]() Now we're at a detailed level, and most coders will not be caught out or have the need for such precision. But I think that's still not a reason to not have it, it's a great bragging right! I'm sure all 68k Assemblers have flaws, including whatever GNU uses for 68k. And this is understood and accepted. In those rare cases I can just declare the opcode. If you want to make AsmPro more powerful, I have a few directive suggestions that I always wanted to see. ![]() |
![]() |
![]() |
#68 |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 347
|
Any new version coming up soon?
![]() |
![]() |
![]() |
#69 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,096
|
Not on the horizon right now. Still haven't decided to fully dig into disassembler because I'd have to allocate a good chunk of time for that and there are too many things on the menu as is. v1.20 will primarily be just more bugfixes, you aren't missing much :P, but if you encounter any problems/bugs let me know and I'll release a new v1.19 build in the meanwhile.
|
![]() |
![]() |
#70 | |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 347
|
Quote:
MyMacro: MACRO move.b d2,(a0,\1.l) ENDM It assembles in Asm-One... Is it my syntax? ![]() |
|
![]() |
![]() |
#71 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
Works for me if you don't have a newline between MyMacro and MACRO. I get (probably expected) "illegal operator" otherwise. How are you exactly defining/invoking it? Use sqaure-open-bracket([) CODE square-close-bracket (]) ... sqaure-open-bracket([) back-slash (/) CODE square-close-bracket (]) to inline some code here
|
![]() |
![]() |
#72 | |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 347
|
Quote:
|
|
![]() |
![]() |
#73 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
|
![]() |
![]() |
#74 |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 347
|
|
![]() |
![]() |
#75 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,096
|
I guess you want this: ($10,a0), or $10(a0) if using the old syntax? If so, the correct way is (\1,a0) or \1(a0). This implies (d16,ax) address reg 16-bit displacement indirect mode.
.L plus placing the offset after Ax implies 020+ full extension addressing. It's basically (d8,ax,ry*scale) but with a 32-bit displacement and supressed index ry. It was implemented that way in order to differentiate between brief and full modes so you could have control what opcode will be generated because there is some overlap. To put it simple... There might be bugs and complications/confusion with full extension addressing, because of all of that. |
![]() |
![]() |
#76 | |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 347
|
Quote:
syntax I mentioned earlier that doesn't work in AsmPro, supports 32-bit offsets in AsmOne. Last edited by oRBIT; 09 August 2023 at 21:45. |
|
![]() |
![]() |
#77 |
Registered User
Join Date: Jan 2023
Location: Denmark
Posts: 9
|
I found this feature in AsmPro .. tested with v1.18 and v1.19c
$B03C0004 CMP.B #4,D0 $0C000004 CMPI.B #4,D0 When AsmPro assembles the Cmp.b, it get turned into Cmpi.b now CMP.B #4,D0 is a leagal opcode. so the quesation is should it be turned into Cmpi ? When I assemble with vasm v1.9e .. it do not get changed. ps: a/b thanks for updating AsmPro |
![]() |
![]() |
#78 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,096
|
Probably shouldn't but it gets away with it because it doesn't matter in 99.99% of situations. It does that not only with cmpi but many other "dual" opcodes, it's the way the parser is written. In this particular case if you write cmp it will ultimately end up using shared code for add/sub/cmp, so all the immediates get an "I".
|
![]() |
![]() |
#79 |
Registered User
Join Date: Jan 2023
Location: Denmark
Posts: 9
|
Ahh right .. I just wanted to mention it, in case it was a problem.
|
![]() |
![]() |
#80 | ||
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,758
|
Quote:
Quote:
Probably there are many instructions that work this way. I.e. cmp.b #4,a0 (or sub.b #4,a0) should have the same effect as the word size instruction, if you write an assembler that encodes the bit for .b. But there might be some instruction word bits that are not ignored on the earlier CPUs, so that if the assembler would encode blindly and the CPU executes blindly could give some interesting side effects. ![]() |
||
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
ASMPro 1.18 on A500/A600? | Antiriad_UK | Coders. Asm / Hardware | 11 | 28 December 2022 10:49 |
AsmPro Macro | REAKTOR BEAR | Coders. Asm / Hardware | 2 | 04 October 2022 13:19 |
AsmPro and INCLUDE sources | OCrowley | Coders. General | 2 | 06 July 2014 11:42 |
AsmPro | copse | Coders. Asm / Hardware | 4 | 25 April 2012 11:41 |
AsmPro | CmdrVimes | Coders. General | 5 | 01 September 2010 12:40 |
|
|