BPTR alignment

[Thomas Richter]

Originally Posted by grond

That's why I wrote "AmigaOS pointers" as opposed to just "pointers". For all other pointers the user should have control anyway.

Not necessarily. Amiga*Os* pointers are also "struct RastPort *", and there is no problem of not having it longword aligned. It's really the dos.library and its clients (handlers) that require it.

Originally Posted by grond

This is more interesting. Are there cases where BPTR are somehow generated by the programmer or are there none?

That depends on the program. The average application program does not require to generate BPTRs, though there are some cases where it becomes necessary, e.g. when creating a "lock list" for the command directory list of the "CommandLineInterface" structure, which is a BPTR-linked list.

[Thomas Richter]

Originally Posted by phx

But even in dos.library you have some unaligned pointers. For example it is no problem when you call Open() with a file name on an odd address.

Yes, though this is more because dos.library calls accepting file names go through a translation layer that generates from the C-string a BSTR, and in the process of doing so, also align it. This (unfortunately) creates the maximum path length of 255 characters.

Originally Posted by phx

Which leads to the more interesting question: is A7 guaranteed to be longword-aligned on program start (from Shell, from Workbench)? I think it is, but I also don't remember seeing it documented somewhere.

Create(New)Proc guarantees stack alignment, and RunCommand() guarantees stack alignment, as both are also dos.library calls, and dos also places some magic on the stack for its BCPL clients. These are the mechanisms by workbench and shell. That, however, does not mean that fellow Amiga programmers haven't tried other forms of program startup bypassing the two, so in general, one cannot assume that.


I do not know how much "__align" of SAS/C really guarantees. It may require that the stack is, on entrance, long word aligned, which may not be true in general if your code is called as part of some other function.


Many Os-internal functions use therefore a macro solution:

#define D_S(type,name) char a_##name[sizeof(type)+3]; \
                       type *name = (type *)((ULONG)(a_##name+3) & ~3UL)
D_S(struct FileInfoBlock,link_fib);

to ensure alignment of those structures that require it. For example the "fib".

[sparhawk]

Originally Posted by Thomas Richter

That depends on the program. The average application program does not require to generate BPTRs, though there are some cases where it becomes necessary, e.g. when creating a "lock list" for the command directory list of the "CommandLineInterface" structure, which is a BPTR-linked list.

When calling Examine() you also have to provide a FileInfoBlock and according to Amiga Intern (Data Becker) it should also be longword aligned.

[Thomas Richter]

Originally Posted by sparhawk

When calling Examine() you also have to provide a FileInfoBlock and according to Amiga Intern (Data Becker) it should also be longword aligned.

Ehem. A couple of comments:

The quesiton was "where do I need to create a BPTR", which is different from "where do I need to align structures". So, to recapitulate:

- Structures you pass into the dos.library have to be longword aligned. Not only struct FileInfoBlock, but pretty much everything. File names are an exception because they are converted to BSTRs anyhow.

- You *typically* do not need to create BPTRs yourself, rather handle them as opaque pointers. You only need to when writing handlers, mounting handlers or for some shell functions.

- Last but not least: Get a better book as reference. "Amiga Intern" is, well, half-baked, half correct information, badly copied from the RKRM and the AmigaDos manual. Get first source material, not "Data Becker" made up information.

[hooverphonique]

Originally Posted by Thomas Richter

I do not know how much "__align" of SAS/C really guarantees. It may require that the stack is, on entrance, long word aligned, which may not be true in general if your code is called as part of some other function.

I think you're on the right track - and if that's the case it only works because the compiler can keep track of what happens with the stack pointer all the way through the code, and is also the reason a similar construct would be unreliable to implement for an assembler, since the user can do anything they like with the stack pointer.

[sparhawk]

Originally Posted by Thomas Richter

- Last but not least: Get a better book as reference. "Amiga Intern" is, well, half-baked, half correct information, badly copied from the RKRM and the AmigaDos manual. Get first source material, not "Data Becker" made up information.

Any recommendations? I also have the RKRM but I find it much harder to read, because it's not as compact and the index is also not really helpfull. I also looked up the online docs, but they are also rather sparse.


I remember Ralph Brown's DOS Interrupt List, which was REALLY detailed and could be compiled into different formats for easy browsing. I was wondering if something like this exists for Amiga as well. Maybe wishfull thinking, but a windows help file would be cool.

[grond]

I very much liked this book: https://gitlab.com/amigasourcecodepr...ll-auf-hundert

While the title doesn't really indicate it, it is just as much about OS coding on the Amiga as about assembly language.

[sparhawk]

This looks pretty good! To bad it's hard to find as a real book. I ordered another one and hope that this is also good: https://www.amazon.de/gp/product/089...?ie=UTF8&psc=1

I'm not so fond of the "Amiga Intern" anyway. On the C64 it was the best book you could get, but for the Amiga it feels just like a rushed translated copy of the RKRM.

I will keep looking for this "Null auf Hundert", maybe I can find it somewhere. Having the PDF is not the same as a real book on your desk.

[grond]

I'm not going to part with mine...

[sparhawk]

And here I was, hoping you don't need it anymore...

[Thomas Richter]

Originally Posted by sparhawk

Any recommendations? I also have the RKRM but I find it much harder to read, because it's not as compact and the index is also not really helpfull. I also looked up the online docs, but they are also rather sparse.

The RKRMs are online available, with permission of its publisher as far as I know. You find there also an index.


I would also recommend the Guru Book, if you can find a copy. As far as the dos.library is concerned, it is a much better source than the official documentation from Bantam Books.


"Intern 2" from Databecker was more or less a German translation of the RKRM Devices and RKRM Libraries, but are now totally outdated as they have not been updated beyond 1.3 - and typical for DataBecker - contain some false information and misunderstandings by its editors.

[sparhawk]

Yet another book, which is hard to come by. Well, at least I know what I will looking for now.

[Edders]

You could have a look at this one - it is in English but available in print!

https://www.amazon.de/dp/1690195150/


Cheers!