[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:	AMIGA NOTES
Notice:	Join us in the NEW conference - HYDRA::AMIGA_V2
Moderator:	HYDRA::MOORE

Created:	Sat Apr 26 1986
Last Modified:	Wed Feb 05 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5378
Total number of notes:	38326

2620.0. "68000 Addressing Limitation ?" by ADOVAX::MCGHIE () Sun Jun 04 1989 05:03

    Hi,
    
    in the process of trying to convert a datafile using BenchMark Modula-2
    I have run into an irritation.
    
    It seems the language insists on even alignment on word and longword
    structures. In fact the manual even goes as far as to say that arrays
    and records are rounded up to an even number of bytes.
    
    So if I have a structure like the following :-
    
    my_record = RECORD
    	my_string: ARRAY [ 1..15 ] OF CHAR;
    	my_int	: INTEGER;
    	my_char	: CHAR;
    	int2	: INTEGER;
    END;
    
    What I end up with, is there is two filler bytes included in the
    structure, one after my_string and one after my_char.
    
    The manual indicates that WORD and LONGWORDs are even byte aligned due
    to limitations in the 68000 architecture. Is this in fact correct ?
    
    If it is then the Modula-2 structures would be compatible with Amiga C
    compiler structures etc.
    
    Have I made the problem (if it is that) clear ?
    
    thanks
    	Mike

T.R	Title	User	Personal Name	Date	Lines
2620.1	Alignment counts	NSSG::SULLIVAN	Steven E. Sullivan	`Sun Jun 04 1989 19:45`	12
	Hi Mike! Been real busy lately... Anyway, here is the answer: yes. The 68000/10 require word alignment of 16 bit and 32 bit quantities. The 68020/30 do not. That is not to say that alignment does not affect performance with the 020/030. It definitely does and having data aligned will payback in definite performance advantages as well as 68000/10 compatibility. Thanks, -SES
2620.2	exit	ADOVAX::MCGHIE		`Sun Jun 04 1989 20:49`	9
	Nice to hear from you, Umm, I presume that means all languages and structures currently used by the Amiga have the problem I outlined in .0 ? thanks Mike
2620.3		CANAM::SULLIVAN	Steven E. Sullivan	`Mon Jun 05 1989 10:47`	3
	Yup! -SES
2620.4	manx c different?	ALASKA::QUIRICI		`Mon Jun 05 1989 12:45`	20
	I have manx C and i was under the impression that the compiler will NOT insert alignment padding within a structure. That is, for example, in the structure structure test { char field_1; long field_2; } field_2 will in fact be offset one character after the start of the structure. I don't know if the compiler will automatically align any structure at word or long addresses, but even it did that would certainly not help in the above case. i do know, as was pointed out in previous replies, that the 68000 requires longs to be long-aligned, etc. is my information about manx C incorrect? ken
2620.5	more on manx c	ALASKA::QUIRICI		`Mon Jun 05 1989 12:57`	9
	actually, now that i think about it, it would have to align field_2 at a long, otherwise the generated code would bomb with an addressing exception (?). Unless it does something more tricky? sorry for the possibly false lead. (feel stupid, or at least ignorant). ken
2620.6	Avoid odd addresses	TLE::RMEYERS	Randy Meyers	`Fri Jun 09 1989 18:45`	15
	Re: .4, .5 The 68000 does require two and four byte objects to be aligned on a word boundary. If they are not (if the address is odd), you do get a Guru 3 (alignment error). As Steve pointed out a few replies back, longs only need to be aligned on a word boundary, not a longword boundary. This makes sense if you think about it: The 68000 is really a 16 bit machine. When it fetches a 32 bit value, it really fetches two 16 bit values and pastes them together. There are some things required to be on a longword boundary, but this is a software, not a hardware issue. The BCPL guts of Amiga DOS stores pointers as normal pointers divided by four. The is because of some BCPL brain damage, and has nothing to do with the 68000 proper.
2620.7	exit	ADOMV1::MCGHIE		`Sun Jun 18 1989 20:02`	4
	Thanks Randy, regards Mike