AsmOne and/or AsmTwo

[guy lateur]

Absolutely!

I've actually gone from what I'd consider the 'easiest' way, ie crosscompiling from C/++ on a PC, to what is possibly the hardest way, ie doing it in assembler (AsmPro) on real hardware.
I'm not exactly sure how that transition came about; I'm kind of weird that way..
And although I do enjoy the 'raw' feeling of doing it this way, checking out the PC route is definitely on my todo list.

I'm doing it this way first because I had a go at assembler programming about 30 years ago, but I never got anywhere with it. So you could say that I'm trying to finally settle some unfinished business.
That, and because everyone keeps telling me it's to 'only true way' to do it.
Oh, and did I already mention [ Show youtube player ]?

[demolition]

Originally Posted by matthey

If you have a Vampire with RTG, then you have enough performance and memory for vasm. It is probably easiest to install the vbcc compiler as you will get vasm and vlink.

http://sun.hasenbraten.de/vbcc/

Then find an editor of your liking, preferably with ARexx (I use CED) and use the BDebug debugger which is in the Barfly package for a power users 68k development environment from the start .

http://aminet.net/dev/asm/BarflyDisk2_00.lha

Thanks for the comments.
The problem is here that I do not want to spend much time setting up the environment although I know that it is usually time well spent in the end. I'd rather get into the coding stuff asap.

I have a vacation coming up soon, so perhaps I will spend some time trying out some stuff and perhaps figure out whether I want to go the Vampire-way or the PC cross-compiler way. Being able to mix gcc objects with assembly stuff also sounds very useful and that also favors going the PC route.

[guy lateur]

I'm trying to link my executable to amiga.lib. I've tried this, as suggested in the guide (although they link to a .o file, rather than a .lib file):

IncLink "work:path/to/amiga.lib"

If I assemble this, AsmPro just hangs while doing Pass1.
So how can I link to amiga.lib?

[Thorham]

Originally Posted by Knocker

I'm not limited by the small screen size

If you have AGA and a VGA dongle, screen space isn't a problem:

[demolition]

Originally Posted by Thorham

If you have AGA and a VGA dongle, screen space isn't a problem:

Not too bad, but still not 2560x1440 like I have on my PC.

But then I do have a 19" monitor above my PC monitor which I use for C64+Amiga, so I don't need to choose one or the other. The main issue is that the two keyboards cannot accopy the same space..

[phx]

Originally Posted by guy lateur

IncLink "work:path/to/amiga.lib"

If I assemble this, AsmPro just hangs while doing Pass1.

Interesting. Never heard about that AsmPro directive yet. What is it doing? Are there any examples or documentation?

When you mention that the guide only shows linking with object files, then it may have problems with libraries. In the best case it would include all objects from that library, which is certainly not what you want.

So how can I link to amiga.lib?

Something like "Write Object" or "Write Linkfile" didn't work?

[alkis]

Originally Posted by guy lateur

So how can I link to amiga.lib?

Why would you want to do that? Do you have an actual case in hand or just foolproofing for the future?

[guy lateur]

Originally Posted by phx

Interesting. Never heard about that AsmPro directive yet. What is it doing? Are there any examples or documentation?

I'm using AsmPro v1.17, which, AFAIK, is the latest version. You can find a little doc on IncLink through the guide: Special Features -> IncLink

Originally Posted by phx

Something like "Write Object" or "Write Linkfile" didn't work?

I don't see how this could my solve my problem. As I understand it, 'Write Link' generates a .o/.lib file which you can then link to. I want my current/executable source to link to an existing .lib file.

[guy lateur]

Originally Posted by alkis

Why would you want to do that? Do you have an actual case in hand or just foolproofing for the future?

See this thread: http://eab.abime.net/showthread.php?t=81416

I would like to XREF the _LVO.. offsets without having to include LVOs.i -- which is pretty big, and I will only be using a very small amount of those declarations.

[alkis]

Yeah, that was my gut feeling.

I think it's sort of wrong. _LVO is just a number. Nothing else.
To introduce a dependency + time overhead to link against the library to eliminate the need for that number is probably the most inefficient way to tackle the problem.

Also, there is another calling convention with amiga.lib You *have* to pass parameters on the stack.

Let's take for example DOSLibrary/Open
From the amiga.lib

00000000 <_Open>:
   0:   48e7 2002       moveml %d2/%a6,%sp@-
   4:   2c79 0000 0000  moveal 0 <_Open>,%a6
   a:   4cef 0006 000c  moveml %sp@(12),%d1-%d2
  10:   4eae ffe2       jsr %a6@(-30)
  14:   4cdf 4004       moveml %sp@+,%d2/%a6
  18:   4e75            rts

And here is the autodoc for Open http://amigadev.elowar.com/read/ADCD.../node0196.html

So, you'd have to pass parameters on stack (forget d1, d2 as the autodocs say), assuming you know what the order of parameters is on stack (it's from right to left btw).

Then you link with amiga.lib

And then the amiga.lib's code, pulls your parameters from stack and feeds d1 and d2 as the autodocs say. (Btw, that -30 is _LVOOpen)

For all the above reasons, linking with amiga.lib when you write in assembly just to call OS functions is less than efficient.

[alkis]

Hmm, got carried away and talked about the C stubs a bit there

Ok, so you just get the LVOOpen number from amiga.lib, the gist of my previous post still stands though. On the link you referenced me, Thorham gave you a single include file with all the LVOs.

Use that. No linking.

[guy lateur]

Originally Posted by alkis

Yeah, that was my gut feeling.

I think it's sort of wrong. _LVO is just a number. Nothing else.
To introduce a dependency + time overhead to link against the library to eliminate the need for that number is probably the most inefficient way to tackle the problem.

Also, there is another calling convention with amiga.lib You *have* to pass parameters on the stack.

Let's take for example DOSLibrary/Open
From the amiga.lib

00000000 <_Open>:
   0:   48e7 2002       moveml %d2/%a6,%sp@-
   4:   2c79 0000 0000  moveal 0 <_Open>,%a6
   a:   4cef 0006 000c  moveml %sp@(12),%d1-%d2
  10:   4eae ffe2       jsr %a6@(-30)
  14:   4cdf 4004       moveml %sp@+,%d2/%a6
  18:   4e75            rts

And here is the autodoc for Open http://amigadev.elowar.com/read/ADCD.../node0196.html

So, you'd have to pass parameters on stack (forget d1, d2 as the autodocs say), assuming you know what the order of parameters is on stack (it's from right to left btw).

Then you link with amiga.lib

And then the amiga.lib's code, pulls your parameters from stack and feeds d1 and d2 as the autodocs say. (Btw, that -30 is _LVOOpen)

For all the above reasons, linking with amiga.lib when you write in assembly just to call OS functions is less than efficient.

Although I kind of get that this may not be the most efficient way of doing this, I'm not sure what you mean by calling dos functions through amiga.lib; I just want the offsets. So what would you say is the most efficient/convenient/standardised way of not having to repeat/include the following code in my own source again and again:

_LVOOpenLibrary equ -552
_LVOCloseLibrary equ -414

[guy lateur]

Originally Posted by alkis

On the link you referenced me, Thorham gave you a single include file with all the LVOs. Use that. No linking.

Could do. I still feel like I'll want to be able to link to some given/precompiled lib's, though, at some point..

[phx]

Originally Posted by guy lateur

I'm using AsmPro v1.17, which, AFAIK, is the latest version. You can find a little doc on IncLink through the guide: Special Features -> IncLink

Ahh, thanks. Got it!

I have read the documentation and made some experiments now. This INCLINK directive is very simplistic. It is not only restricted to a single object file, but also to a single section. It doesn't help you in any way.

As I understand it, 'Write Link' generates a .o/.lib file which you can then link to. I want my current/executable source to link to an existing .lib file.

You are confused. Write Link (wl) is exactly what you want.
You cannot link executables or source texts. Only object files.

Assemble your current source with AsmPro. Then write the object file with "wl", for example as "main.o". Finally link it against amiga.lib:

vlink -bamigahunk -nostdlib -o myprog main.o -LAmigalibPath -lamiga

Tried it here with AsmPro 1.17 and vlink 0.16. Works!

[guy lateur]

Originally Posted by phx

Assemble your current source with AsmPro. Then write the object file with "wl", for example as "main.o". Finally link it against amiga.lib:

vlink -bamigahunk -nostdlib -o myprog main.o -LAmigalibPath -lamiga

Tried it here with AsmPro 1.17 and vlink 0.16. Works!

Fantastic, I can confirm this works, thanks a lot!

Originally Posted by phx

You are confused. Write Link (wl) is exactly what you want.
You cannot link executables or source texts. Only object files.

I was very confused, indeed, so thanks for trying to set me straight on this! I'm still a little confused, though, so here are a couple more questions:

1. What's the difference (if any) between a .o file and a .lib file? Can I make my own .lib files? When would I want to do that?
2. I'm assuming (as I've seen it) you can link several .o files together in 1 go. How does the linker know where the main entry-point is?

[phx]

Originally Posted by guy lateur

1. What's the difference (if any) between a .o file and a .lib file?

An object file (usually with .o or .obj suffix) is an indivisible part of your program, containing symbol definitions and unresolved references, which is always completely included in the executable, when specified on the command line.

A static linker library (usually with .lib or .a suffix) is a collection of multiple object files. The linker will include an object module from such a library in the linking process, as soon as one of its symbol definitions was referenced from already included code.

There are also dynamic link libraries (for example with .so or .dll suffix), which are more or less a big object file which is loaded/mapped into memory and dynamically linked with the executable at run-time. Here the linker just checks if referenced symbols exist, and notes the needed dynamic library names and search-paths in the executable. On the Amiga these libraries only exist in AmigaOS4.1.

Some linkers (for example GNU-ld and vlink) also support section garbage collection, which has the effect that those sections from an object file, without any references on it, are removed. So even an object file is not that indivisable anymore.

Can I make my own .lib files? When would I want to do that?

You want to use a linker library whenever you have a collection of functions, where some of your programs only need a subset of them. Linking against a library makes sure that only the needed object modules are included in the final executable, which saves space.

There are different types and formats of libraries. On AmigaDOS/68k the typical linker library is just a series of hunk-format object files, joined together. For example:

join obj1.o obj2.o obj3.o as my.lib

Also more sophisticated formats, optimized for size and link-speed, exist. Like the HUNK_LIB format, introduced by SAS/C. You will need special tools to create them.

2. I'm assuming (as I've seen it) you can link several .o files together in 1 go. How does the linker know where the main entry-point is?

Linking several object files together is the reason for the linker's existence.

The main entry point either depends on the OS or the object file format. We are talking here about AmigaOS/68k, using hunk format. In this case the OS always enters the executable at the first word of the first section. So you have to make sure that the first section of the first object file on the command line contains your startup code. The linker cannot help you here.

Other formats, like ELF, can define an entry point in the header, and you can set it with linker options or in a linker script.

[guy lateur]

Thanks a lot for taking the time to explain this, phx, I really appreciate this!

[demolition]

Yes, very clear and understandable explanation.

[demolition]

Originally Posted by matthey

Then find an editor of your liking, preferably with ARexx (I use CED) and use the BDebug debugger which is in the Barfly package for a power users 68k development environment from the start .
http://aminet.net/dev/asm/BarflyDisk2_00.lha

I tried running BarFly/Basm on my A500 with ACA500plus+ACA1221ec but it complained that it needed an 68020+ to run.. As far as I can see, the CPU on the ACA1221ec looks like a genuine 020 and WhichAmiga/SysInfo also writes 68020.
Haven't tried whether it wants to run on the Vampire.

Bdebug seemed to start, although I haven't tried using it yet.

Currently I started trying out some stuff with Asm-Pro and have gone through most of Photon's lovely tutorial videos. What I could really use, are some reference manuals in book-form as I can't recite all the addresses from memory like some of you might be able to. Those books are not too easy/cheap to get a hold of unfortunately.

Any suggestions in regards to some memory maps / custom chip register lists that are designed for A4 print outs?

[phx]

Originally Posted by demolition

Any suggestions in regards to some memory maps / custom chip register lists that are designed for A4 print outs?

Get this: http://ada.evergreen.edu/~tc_nik/fil...dRefManual.pdf
And print it. The HRM is all you need for Amiga hardware programming.