English Amiga Board


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

 
 
Thread Tools
Old 17 January 2015, 16:00   #21
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 47
Posts: 1,838
Then you can use data section, or use one of the work arounds posted earlier, except for the one posted by Don which is incorrect - just calculate the number of bytes generated if the difference from the start of the section is e.g. 50...
IFW is offline  
Old 17 January 2015, 22:29   #22
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 50
Posts: 1,049
Quote:
Originally Posted by phx View Post
No. It doesn't. "section bss" is a code section, named "bss". Watch the $3e9 hunk type in your output. "section name,bss" or just "bss" would be a real bss section. Omitting the section type lets it default to code.


Correct. The first data in a section is always guaranteed to start on a 8-byte boundary. When a linker combines sections, the following data is still guaranteed to start on a 4-byte boundary, as a hunk size is always a multiple of 4.
Of course not, first data in a section is always guaranteed to start on a 4-byte boundary, or you must use modified exec.library, if you want to start f.e. on a 8 byte boundary. You can read Jim Drew's posts about random Fusion speed.
Don_Adan is offline  
Old 17 January 2015, 22:45   #23
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
What makes you think so? All sections I have ever seen start on an 8-byte boundary in memory, because LoadSeg() allocates them with AllocMem().

Which post of Jim Drew? Any links?
phx is offline  
Old 17 January 2015, 23:22   #24
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by phx View Post
What makes you think so? All sections I have ever seen start on an 8-byte boundary in memory, because LoadSeg() allocates them with AllocMem().

Which post of Jim Drew? Any links?
Jim was using a patch which aligned memory allocations more so they would be compatible with his Fusion Mac Emulator which uses MOVE16. It's not in widespread use but Chris Hodge's TLSFMem is:

Quote:
Originally Posted by Chris Hodges in TLSFMem.readme
Q: Does this 103% stuff mean it wastes memory (internal fragmentation)?
A: No. It only needs four extra bytes per allocation. The only internal
fragmentation happening is for its alignment of 16 bytes per allocation.

...

- Uses four additional bytes per allocation and has a minimum chunk size of
16 instead of 8.
This makes CNOP 0,16 useful to align to a cache line. It should speed up memory copies with a CopyMem patch that uses MOVE16 as well as vbcc floating point although the difference would be small (a few percent?).

Devpac missing alignment functionality isn't as bad as with C. Without GCCisms, one must use _Alignas from C11. Vbcc does support __alignof already so something like the following C11 stdalign.h should be possible.

Code:
#ifndef __STDALIGN_H
#define __STDALIGN_H

/* #define __alignas _Alignas */
#define __alignof _Alignof

#define __alignas_is_defined 0
#define __alignof_is_defined 1

#endif /* __STDALIGN_H */
All we need is __alignas support in vbcc but this is trickier than __alignof beause of limitations on minimum and maximum valid alignment. It might be worth suggesting to Volker. I hope he isn't waiting for vbcc to be 100% C99 compliant before he adopts some good ideas from C11 .

Last edited by matthey; 17 January 2015 at 23:30.
matthey is offline  
Old 23 January 2015, 20:47   #25
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 600
Devpac can use any memory alignment (CNOP 0,16 - CNOP 0,128, etc.) I used CNOP 0,16 throughout FUSION, PCx, and anything that is going to be doing a bunch of stuff that I want to be guaranteed to be entirely in the cache.
JimDrew is offline  
Old 24 January 2015, 00:18   #26
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by JimDrew View Post
Devpac can use any memory alignment (CNOP 0,16 - CNOP 0,128, etc.) I used CNOP 0,16 throughout FUSION, PCx, and anything that is going to be doing a bunch of stuff that I want to be guaranteed to be entirely in the cache.
Sure, you can specify CNOP 0,16 in Devpac but will you get it without a patch to AmigaOS that aligns memory allocations or hunks to more than 8 byte alignment? The start of the hunk has to have the same alignment or better than the CNOP alignment specified or the alignment may be less than requested.
matthey is offline  
Old 24 January 2015, 00:57   #27
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,201
Bigger alignments than 8 make sense when you don't use the AmigaDOS hunk format, but assemble for an absolute address.

Let's say you start your code with "org $10000". This will allow alignments up to "cnop 0,65536"...
phx is offline  
Old 09 February 2015, 20:43   #28
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 600
Quote:
Originally Posted by matthey View Post
Sure, you can specify CNOP 0,16 in Devpac but will you get it without a patch to AmigaOS that aligns memory allocations or hunks to more than 8 byte alignment? The start of the hunk has to have the same alignment or better than the CNOP alignment specified or the alignment may be less than requested.
You do if you use a custom hunk loader! ALL of my programs use a loader program that locates ALL code hunks on a 16 byte alignment. This the "patch" that was referred to early. It's not really a patch, its an executable loader program called "load", ie: load <filename>

For PCx the script file was:

RUN >NIL: <NIL: load PCx.dat

The load program makes AIBB, SysInfo, and a variety other benchmarks give you the same results every time.
JimDrew is offline  
Old 09 February 2015, 22:24   #29
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Use RS to define your data structures, then put a single dcb.b in the BSS hunk with the total byte size.

Then one can do
Code:
__RS set ((__RS-1)|3)+1
or somesuch
Mrs Beanbag is offline  
Old 15 February 2015, 05:42   #30
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
The basic problem is that CNOP is just a way of aligning data, a replacement for modifying "*" (program counter) as allowed by older assemblers. In a BSS section, it should become a DS and in code or data sections, it should become a DC of the appropriate size. Or the assembler should just skip a few bytes in memory in all cases, it should not matter to the developer.

It's a silly directive name, anyway. There's no real condition and certainly no CPU NOP instruction involved anywhere.
Photon is offline  
Old 19 March 2015, 00:12   #31
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Moved to the Assembler forums where it should be.
Photon is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
cnop phx Coders. Asm / Hardware 13 19 February 2015 22:33
newest ami/x and cnet bss GreenMeanie request.Apps 1 16 September 2011 21:12
Off-topic section BippyM project.EAB 3 29 January 2007 18:08
Section 8 ??? plasmatron Nostalgia & memories 4 04 June 2004 21:40
Federation of the Free Traders + BSS Jane Seymour haynor666 MarketPlace 0 06 June 2003 16:19

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 07:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.07702 seconds with 13 queries