Re: [Sdcc-user] 6502 and AS

[Borut R. <bor...@gm...>]

On 16. 03. 2013 12:54, Masur Jonathan wrote:
> Le 16.03.2013 01:13, Borut Ražem a écrit :
>> Helo Jonathan,
>>
>> sdas and sdld are actually a fork of Alan Baldwin's ASXXXX assembler
>> (see http://shop-pdp.net/ashtml/asxxxx.htm) with some sdcc related
>> modifications. Only the targets supported by sdcc are included in
>> sdas/sdld but the documentation includes all ASXXXX targets, as you
>> already noticed, All sdcc targets except pics generate assembly code
>> primarily (or exclusively) for sdas / sdld. So the natural choice for
>> sdcc 6502 target wold be the ASXXXX assembler, which already include
>> support for 6502.
> Thanks, this made things a little bit clearer. Did Alan Baldiwn's ASXXX
> change much since the sdcc fork or is it still pretty much the same ? In
> any case it sounds like it would be fairly trivial to port his version
> of ASXXX to the SDAS fork.

There is ongoing project to resynchronize sdas/sdld with the latest 
ASXXXX version: I did some work in this direction quite some time ago 
mainly in the linker area an Maarten synced the assemblers. Amount of 
deviation from the original also depends on the target. Maybe Leland 
Morrison can give you much more in-deep information since he implemented 
Rabbit 2000/3000/3000A support not so far ago.

>> There is an other component needed when implementing a new sdcc target:
>> the simulator. It is indispensable for testing the generated code and
>> for running regression tests. You can use any open source simulator you
>> can find, but the natural choice is ucsim, used by all sdcc targets
>> expect pics. Unfortunately uscim doesn't support 6502 yet, so this part
>> should be implemented too,
> You are very right, in fact I tought that a hardware simulator using an
> FPGA would be cooler, but in any case I think I can't avoid ucsim so
> I'll have to see how it works for other CPUs first...
>
> There is already dozen of very accurate 6502 simulators, Visual6502 is
> very popular. Not to mention all the C64 and NES emulators.

The simulator should be:
- open source
- easily portable to all platforms used for sdcc regression testing (see 
http://sdcc.sourceforge.net/snap.php)
- fully command line driven so that it can be used in automated 
regression testing

> Le 16.03.2013 00:38, Richard Gray a écrit :
>   > I'm dredging my memory, but back in the '80s this problem was
> "solved" by a
>   > pseudo-instruction, LDAZ, meaning load zero-page. I wrote an
> assembler myself
>   > for the 6502 back in the 1980's, and I seem to recall this is how I
> did it. I
>   > don't think there's a reliable way of deducing whether a zero-page
> instruction
>   > is appropriate otherwise.
>
>
> The problem is that it is absolutely not compatible with the
> standardized 6502 instruction set.
>
> I already some assembler who handles it unconventional ways, like
>
> lda general_variable
> lda <zero_page_variable
>
> for NESASM
>
> and
>
> lda zero_page_variable.b
> lda general_variable.w
>
> for WLA-DX
> (it would actually default to zero-page and send an error if you ommit
> the ".w" suffix when accedding a label which is not zero page - this is
> not required if the address is a direct number greater than $100).
>
>
> As far as I know, many assemblers in the '80s did not allow for
> relocatable code (= no linker), and this was sovled with multple passes
> in assembly :
> Pass 1 : Parse all the variable declarations, labels, etc... and assign
> them to a cathegory (zero page or not zero page)
> Pass 2 : Parse all the code, now that we know where the labels are it's
> possible to assemble the code. Since no relocatable code was used, they
> just changed the PC with .org or similar directive and didn't ask
> themselves more questions.
>
> As you can see pass 1 is not exactly equal to assembling and pass 2 is
> not equal to linking, as the code size is completely unknown on pass 1.
>
> This worked fine in many cases, but caused problem if you wanted your
> code to be relocatable, i.e. you copy it from ROM to RAM and execute
> form RAM for example. Or in the Commodore 64, you copy the code from RAM
> to the disk drive which has a completely different 6502 with a different
> address space. In both case the code needs to be relocatable to work and
> only a true linker can do this.
>
> This can probably be solved with two pass assembly + one linking pass (3
> passes in total). I'll have to check how CA65 and LD65 handles this problem.
> In all cases, the closer the assembler is to the official syntax, the
> better.
>
> I also do not like that apparently ASXXX 6502 wants to use [] brackets
> for indirection instead of the standard () brackets.
> This is probably simple to change though.

This is probably because the parentheses are used for expressions. In 
this case use of square brackets seems more appropriate to me. But I'm 
only guessing...

P.S.: There is an other thing I want to mention here: there were many 
attempts to add new targets to sdcc in it's history, but many of them 
infamously failed. The problem is that adding a target is not a trivial 
job: it requires a huge amount of work which is never finished. Many 
developers started to work on new targets but then lost the interest or 
didn't have enough time to continue. Such cases cause nothing else but 
mess and problems to the whole sdcc project. So, if you have serious 
intentions, we can integrate your work directly into the sdcc project. 
If not it is better to create a totally separate project and eventually 
merge it with the original sdcc if/when it is considered to be stable 
enough. In this case your project should keep to be synchronized with 
sdcc as much as possible in order to make the (potential) re-merge as 
simple as possible.

Good luck,
Borut