EmuTOS

Hello, Henk.

I've seen your latest AHCC changelog, once again you made a huge amount of 
work !

I've just tried the EmuTOS ROM shipped in your archive, unfortunately it 
doesn't work.

It crashes ARAnyM, and Hatari displays a nice error message.

Look at the first bytes of the ROM, and compare them with the official binary.

Official:
60 2E 02 06

AHCC version:
60 FF 00 00 00 32 02 06

The source is bios/startup.S:
_os_entry:
     bra.s   _main       // os_entry, branch to _main
os_version:
     dc.w    TOS_VERSION // os_version, TOS version

In your version, the bra.s has been turned into bra.l, which is certainly a 
mistake because such implicit conversion could never be valid. Then the 
other header fields are not at the right place.

I'm sure you will fix this easily.

-- 
Vincent Rivière

Vincent Rivière wrote:

> In your version, the bra.s has been turned into bra.l, which is certainly a 
> mistake because such implicit conversion could never be valid. Then the 
> other header fields are not at the right place.
> 
> I'm sure you will fix this easily.
> 

Oops, the punishment for too much confidence.
I compiled Emutos and forgot to run it.

Thanks.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Vincent Rivière wrote:

> The source is bios/startup.S:
> _os_entry:
>      bra.s   _main       // os_entry, branch to _main
> os_version:
>      dc.w    TOS_VERSION // os_version, TOS version
> 
> In your version, the bra.s has been turned into bra.l, which is certainly a 
> mistake because such implicit conversion could never be valid. Then the 
> other header fields are not at the right place.

I have refreshed emutos_ahcc.zip on my homepage.
This time I didnt forget to run it. :-)
It now works as I described.

Is there a easy way to make disk images for emutos on Aranym?
I would like to run programs from the emutos desktop.

The fix in AHCC will appear in the next release.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Henk Robbers píše v St 09. 12. 2009 v 13:16 +0100:
> Is there a easy way to make disk images for emutos on Aranym?

yes, it's very easy using the SETUP GUI.
Just don't forget to partition and format the disk afterwards using AHDI
or some other free or commercial disk utility.

Petr

Petr Stehlik wrote:
> Henk Robbers píše v St 09. 12. 2009 v 13:16 +0100:
> 
>>Is there a easy way to make disk images for emutos on Aranym?
> 
> 
> yes, it's very easy using the SETUP GUI.
> Just don't forget to partition and format the disk afterwards using AHDI
> or some other free or commercial disk utility.
> 

Ah! Thanks.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Henk Robbers wrote:
> I have refreshed emutos_ahcc.zip on my homepage.
> This time I didnt forget to run it. :-)
> It now works as I described.

Henk, I have tested your ROM with one of my familar ARAnyM setup, and I
noticed several abnormal things.

1) The EasyMiNT version displayed on the EmuTOS screen. It should be 0.8.4,
but in your version it is 8.4

2) In ARAnyM, when I press the Pause key then the Reboot button, only the 
desktop is restarted, I don't see the EmuTOS screen again.

3) There is a real problem with the files. With a normal EmuTOS I can see 
the files in my C drive. With your ROM, when I double-click the C icon the 
window is empty, 0 bytes, 0 items. Same in EmuCON.

-- 
Vincent Rivière

Vincent Rivière wrote:
> Henk Robbers wrote:
> 
>>I have refreshed emutos_ahcc.zip on my homepage.
>>This time I didnt forget to run it. :-)
>>It now works as I described.
> 
> 
> Henk, I have tested your ROM with one of my familar ARAnyM setup, and I
> noticed several abnormal things.
> 
> 1) The EasyMiNT version displayed on the EmuTOS screen. It should be 0.8.4,
> but in your version it is 8.4

I think I did it myself.
The version comes from the GNU make script isnt it?

> 2) In ARAnyM, when I press the Pause key then the Reboot button, only the 
> desktop is restarted, I don't see the EmuTOS screen again.
> 
> 3) There is a real problem with the files. With a normal EmuTOS I can see 
> the files in my C drive. With your ROM, when I double-click the C icon the 
> window is empty, 0 bytes, 0 items. Same in EmuCON.
> 

OK thanks. So it is not ready yet. I will do the rest of the testing
myself. I think I know how to make a disc image. Usefull anyhow.

It might be a small issue.
Does GCC let functions return pointers in A0 or in D0?
I thought I knew, but now I am not sure anymore.

AHCC is really still beta.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Hi,

On Wednesday 09 December 2009, Vincent Rivière wrote:
> Henk, I have tested your ROM with one of my familar ARAnyM setup, and I
> noticed several abnormal things.
>
> 1) The EasyMiNT version displayed on the EmuTOS screen. It should be
> 0.8.4, but in your version it is 8.4
>
> 2) In ARAnyM, when I press the Pause key then the Reboot button, only the
> desktop is restarted, I don't see the EmuTOS screen again.

In Hatari, I don't see the EmuTOS startup screen with this binary even on
first boot, except when emulating Falcon.  (there warn reset results in not
seeing the startup screen either)


> 3) There is a real problem with the files. With a normal EmuTOS I can see
> the files in my C drive. With your ROM, when I double-click the C icon
> the window is empty, 0 bytes, 0 items. Same in EmuCON.

Works fine in Hatari:
	hatari --tos emutos/etos512k.img -d emutos

And on quick testing things seem to be otherwise working more
or less like with the normal emutos release except that  AHCC compiled
EmuTOS version panics to bus error on bootup when running Cecile HD
driver from a flopping image:
	hatari --tos emutos/etos512k.img --machine tt -m --ide-master 
HDD-32MB.image cecile.st

(no panic with normal EmuTOS release)


	- Eero

Maybe it is a A6 issue.
There has been 1 found already by Vincent
(and by me independently).

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Henk Robbers a écrit :
> Does GCC let functions return pointers in A0 or in D0?
> I thought I knew, but now I am not sure anymore.

The Atari GCC returns pointers in D0.

NB: This is configurable in GCC. On some m68k platforms, pointers are 
returned in a0. On some others, pointers are returned in both d0 and a0 
to avoid to break compatibility (illness). In early days I configured 
GCC to return pointers into a0 then I had been severely flamed (probably 
here, if I remember well). Then I reverted the settings to the venerable 
GCC 2.95 behaviour. Pointers returned in d0 only.

However, there is an issue with returning pointers in a0.
If a function returning a pointer is called without the presence of a 
prototype, which is bad but allowed, the caller will get the result from 
d0 (by default), while the callee put it into d0...

-- 
Vincent Rivière

On Thu, 10 Dec 2009 01:59:02 +0200
Eero Tamminen <oak@...> wrote:

> Hi,
> 
> On Wednesday 09 December 2009, Vincent Rivière wrote:
> > Henk, I have tested your ROM with one of my familar ARAnyM setup,
> > and I noticed several abnormal things.
> >
> > 1) The EasyMiNT version displayed on the EmuTOS screen. It should be
> > 0.8.4, but in your version it is 8.4
> >
> > 2) In ARAnyM, when I press the Pause key then the Reboot button,
> > only the desktop is restarted, I don't see the EmuTOS screen again.
> 
> In Hatari, I don't see the EmuTOS startup screen with this binary
> even on first boot, except when emulating Falcon.  (there warn reset
> results in not seeing the startup screen either)

Petr changed the behaviour of the startup screen some months ago. It's
now only showed when the memory configuration is not valid yet, i.e.
only during the first cold boot on a real machine. On Hatari, memory
configuration is always valid (at least in ST mode), so you don't see
this screen there anymore.

 Thomas

On Wed, 09 Dec 2009 23:17:13 +0100
Henk Robbers <h.robbers@...> wrote:

> Vincent Rivière wrote:
> > Henk Robbers wrote:
> > 
> > Henk, I have tested your ROM with one of my familar ARAnyM setup,
> > and I noticed several abnormal things.
> > 
> > 1) The EasyMiNT version displayed on the EmuTOS screen. It should
> > be 0.8.4, but in your version it is 8.4
> 
> I think I did it myself.
> The version comes from the GNU make script isnt it?

Right, the version in "official" EmuTOS is generated from the
changelog.txt by a rule in the Makefile.

 Thomas

Thomas Huth píše v Čt 10. 12. 2009 v 23:38 +0100:
> Petr changed the behaviour of the startup screen some months ago. It's
> now only showed when the memory configuration is not valid yet, i.e.
> only during the first cold boot on a real machine.

it now behaves just like the original TOS

> On Hatari, memory configuration is always valid

how can you have a valid memconfig after power on? :-O

Petr

Vincent Rivière wrote:
> Henk Robbers a écrit :
> 
>>Does GCC let functions return pointers in A0 or in D0?
>>I thought I knew, but now I am not sure anymore.
> 
> 
> The Atari GCC returns pointers in D0.
> 
> NB: This is configurable in GCC. On some m68k platforms, pointers are 
> returned in a0. On some others, pointers are returned in both d0 and a0 
> to avoid to break compatibility (illness). In early days I configured 
> GCC to return pointers into a0 then I had been severely flamed (probably 
> here, if I remember well). Then I reverted the settings to the venerable 
> GCC 2.95 behaviour. Pointers returned in d0 only.
> 

OK, I'll make a binary with pointers in D0 and A0.
A0 because it is the behaviour of Pure C and AHCC.

I'll also check all A6 usage. Including Cecily.

> However, there is an issue with returning pointers in a0.
> If a function returning a pointer is called without the presence of a 
> prototype, which is bad but allowed, the caller will get the result from 
> d0 (by default), while the callee put it into d0...
> 

ANSI C is the result of a lobby of incompetent compiler writers.

No prototype ? error: undefined name!!!!

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Hi Henk,

> ANSI C is the result of a lobby of incompetent compiler writers.
> 
> No prototype ? error: undefined name!!!!

Thats why we often called C a better assembler. In the past when i
started to work, i often wondering, why such a unsecure language was
so common.

Best regards
Michael

Henk Robbers wrote:

> 
> OK, I'll make a binary with pointers in D0 and A0.
> A0 because it is the behaviour of Pure C and AHCC.

Hmm, I already did this half a year ago.
It is still there.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Henk Robbers a wrote:
>> OK, I'll make a binary with pointers in D0 and A0.
>> A0 because it is the behaviour of Pure C and AHCC.
>
> Hmm, I already did this half a year ago.
> It is still there.

Beware, hand-written assembler functions return pointers in d0 only, such as 
util/memset.S

-- 
Vincent Rivière

Vincent Rivière wrote:
> Henk Robbers a wrote:
> 
>>>OK, I'll make a binary with pointers in D0 and A0.
>>>A0 because it is the behaviour of Pure C and AHCC.
>>
>>Hmm, I already did this half a year ago.
>>It is still there.
> 
> 
> Beware, hand-written assembler functions return pointers in d0 only, such as 
> util/memset.S
> 

The above caters for C called from assembly.

And yes, I have to check all assembly called from C.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Michael Bernstein wrote:
> Hi Henk,
> 
> 
>>ANSI C is the result of a lobby of incompetent compiler writers.
>>
>>No prototype ? error: undefined name!!!!
> 
> 
> Thats why we often called C a better assembler. In the past when i
> started to work, i often wondering, why such a unsecure language was
> so common.

C was designed for writing a portable operating systems
by skilled specialists. *)
Assembly was out of the question.
Cobol, Fortran and PL/I were a disaster.
Algol60 was not flexible enough and nobody understood Algol68
or there was simply no Algol68 compiler yet.

*) I must admit that it was exactly there where it went wrong. ;-)

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Hi,

On Wednesday 09 December 2009, Henk Robbers wrote:
> I have refreshed emutos_ahcc.zip on my homepage.

I took a quick look at the changes (mostly ones marked with __AHCC__):

* new files:
  include/ahcc_rt.h
  include/biosahcc.h
  include/xbiosahcc.h
* use of AHCC specials instead of GCC inline asm:
  include/asm.h
* use (x)biosahcc.h instead of stuff here:
  include/biosbind.h
  include/xbiosbind.h

Which seemed more or less OK if AHCC support is wanted in EmuTOS
(which I think nice, but then I'm not an EmuTOS developer :-)).


I think in "bios/disk.c":
--------
#if __AHCC__                                    /* no dynamic init */
                        char pid[3];

                        pid[0] = 0;
                        pid[1] = 'D';
                        pid[2] = type;
#else
            char pid[3] = {0, 'D', type };
#endif
--------
EmuTOS could just use the C89 syntax instead of C99 GCC supported one.
Same for the array initializations and use of bool which in code were marked
just with the "HR" comments[1].


There was something that looked like a bug in "bios/ikbd.c":
-------
    WORD old_sr;
    LONG value;

    /* keep current value of sr before changing it using STOP */
#if __AHCC__
        get_sr(old_sr);
#else
    old_sr = get_sr();
#endif
-------

Unless you give *old_sr to get_sr(), how it could work?


I don't understand this change in "bios/bios.c" either:
-------
#if __AHCC__
    exec_os = ui_start;        /* set start of user interface */
#else
    exec_os = &ui_start;        /* set start of user interface */
#endif
-------


There was also something suspicious looking in "bios/atari_rootsec.h":
---------
#if __AHCC__
};
#else
} __attribute__ ((__packed__));
#endif
---------

Does AHCC make all structures packed (not padded) by default?

When looking at the structure, I'm wondering about the need for the packed 
attribute thought.  All members are at least word aligned which, if I
remember right, should be enough on 680x0.  Does GCC make 32-bit
structure members 32-bit aligned by default for performance reasons?


Also, what's the issue here:
-----------
static void setvalue_snd(void)
{
  /* always at least a PSG */
  cookie_snd = 1;

#if 0           /* HR: got a hang with this code */
  /* Check for DMA sound */
  if (check_read_byte(0xFFFF8903)) {
    cookie_snd |= 2;
  }
#endif
}
-----------
?


	- Eero

[1] grep ' HR[: ]' $(find -name '*.[hcS]')

LS

I am very busy now. I will look at all this later as part
of the implementation of the Coldfire target in AHCC.

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Eero Tamminen wrote:
> When looking at the structure, I'm wondering about the need for the packed
> attribute thought.  All members are at least word aligned which, if I
> remember right, should be enough on 680x0.  Does GCC make 32-bit
> structure members 32-bit aligned by default for performance reasons?

__attribute__ ((__packed__) is evil: more than removing all the fillers, it 
assumes that the structure can be stored on an odd address. On 680x0, it 
means that all access to shorts and longs in the structure will be done byte 
by byte with move.b to avoid a potential address error ! This can lead to a 
severe performance degradation.

My port of GCC 4.4.2 aligns nothing to more than 2 bytes, and I believe it 
is the same for all other Atari ports. So as you underline, in the struct 
rootsector the __attribute__ ((__packed__) is useless, and it hurts the 
performance. I think it should be removed.

-- 
Vincent Rivière

On Thu, 7 Jan 2010 21:44:59 +0200
Eero Tamminen <oak@...> wrote:

> Hi,
> 
> On Wednesday 09 December 2009, Henk Robbers wrote:
> > I have refreshed emutos_ahcc.zip on my homepage.
> 
> I took a quick look at the changes (mostly ones marked with __AHCC__):

You should have checked the EmuTOS CVS first, I've already merged some
of Henk's changes a couple of weeks ago! (but I left out the things
that were too much AHCC specific, I don't want to spoil the code with
too much #ifdefs).

> There was something that looked like a bug in "bios/ikbd.c":
> -------
>     WORD old_sr;
>     LONG value;
> 
>     /* keep current value of sr before changing it using STOP */
> #if __AHCC__
>         get_sr(old_sr);
> #else
>     old_sr = get_sr();
> #endif
> -------
> 
> Unless you give *old_sr to get_sr(), how it could work?

AHCC seems to provide some magic intrinsic functions for this (see
asm.h):

#if __AHCC__
#define get_sr(a) __ldsr__(a)
#else
...

> 
> I don't understand this change in "bios/bios.c" either:
> -------
> #if __AHCC__
>     exec_os = ui_start;        /* set start of user interface */
> #else
>     exec_os = &ui_start;        /* set start of user interface */
> #endif
> -------

I think both is legal C code, however AHCC seems only to support one
flavour.

> 
> When looking at the structure, I'm wondering about the need for the
> packed attribute thought.  All members are at least word aligned
> which, if I remember right, should be enough on 680x0.  Does GCC make
> 32-bit structure members 32-bit aligned by default for performance
> reasons?

I'm not sure but it might do so when compiling for 68030 CPUs...?

 Thomas

Thomas Huth wrote:

> 
> AHCC seems to provide some magic intrinsic functions for this (see
> asm.h):
> 
> #if __AHCC__
> #define get_sr(a) __ldsr__(a)
> #else
> ...

:-)

I have provided AHCC specific operations
for the most common privileged instructions a OS needs.
This was easier and quicker than implementing inline assembly.
(And more secure)

I think they are described in the hypertext, maybe too concise.

In theory I could provide the complete assembler
instruction set this way.
In contrast to GCC, assembly language is part of the front end
so AHCC already knows them all, and what they ref and clobber. ;-)

__ldsr__(a) generates move sr,a

I agree that this example is not really nice.
I might do better, I'll have a look.
It is much nicer to retain the a = get_sr()

-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Hi,

On Friday 08 January 2010, Thomas Huth wrote:
> > I took a quick look at the changes (mostly ones marked with __AHCC__):
>
> You should have checked the EmuTOS CVS first, I've already merged some
> of Henk's changes a couple of weeks ago!
...
> > I don't understand this change in "bios/bios.c" either:
> > -------
> > #if __AHCC__
> >     exec_os = ui_start;        /* set start of user interface */
> > #else
> >     exec_os = &ui_start;        /* set start of user interface */
> > #endif
> > -------
>
> I think both is legal C code, however AHCC seems only to support one
> flavour.

I see, ui_start was a function.  Yes, I think for those direct value and
address of a function are the same...


This value change looks also strange:
http://emutos.cvs.sourceforge.net/viewvc/emutos/emutos/bios/mfp.h?r1=1.6&r2=1.7

(MFP_BASE: 0x00fffa00L -> 0xfffffa00L)

Was the earlier value a bug?


	- Eero

Eero Tamminen píše v Pá 08. 01. 2010 v 13:32 +0200:
> > > #if __AHCC__
> > >     exec_os = ui_start;        /* set start of user interface */
> > > #else
> > >     exec_os = &ui_start;        /* set start of user interface */
> > > #endif
> > > -------
> >
> > I think both is legal C code, however AHCC seems only to support one
> > flavour.
> 
> I see, ui_start was a function.  Yes, I think for those direct value and
> address of a function are the same...

Yet I would prefer enhancing the compiler instead of polluting the
applicatoin source code.

> This value change looks also strange:
> http://emutos.cvs.sourceforge.net/viewvc/emutos/emutos/bios/mfp.h?r1=1.6&r2=1.7
> 
> (MFP_BASE: 0x00fffa00L -> 0xfffffa00L)

> Was the earlier value a bug?

No, the latter is bug. The MFP BASE is at 0x00fffa00L.

Petr

Petr Stehlik wrote:
> Eero Tamminen píše v Pá 08. 01. 2010 v 13:32 +0200:
> 
>>>>#if __AHCC__
>>>>    exec_os = ui_start;        /* set start of user interface */
>>>>#else
>>>>    exec_os = &ui_start;        /* set start of user interface */
>>>>#endif
>>>>-------
>>>
>>>I think both is legal C code, however AHCC seems only to support one
>>>flavour.
>>
>>I see, ui_start was a function.  Yes, I think for those direct value and
>>address of a function are the same...
> 
> 
> Yet I would prefer enhancing the compiler instead of polluting the
> applicatoin source code.

I disagree. Spuriosity is pollution. It would not be a enhancement.
How do you define spuriosity in a language?
Leaving out everything that is nonsense?
What if I really want a pointer to a pointer to a function?
It is better to remove it because it is confusing.

But yes, AHCC has a problem here.
Interpretation of nonsense correctly is a weak point of AHCC.

> 
>>This value change looks also strange:
>>http://emutos.cvs.sourceforge.net/viewvc/emutos/emutos/bios/mfp.h?r1=1.6&r2=1.7
>>
>>(MFP_BASE: 0x00fffa00L -> 0xfffffa00L)
> 
> 
>>Was the earlier value a bug?
> 
> 
> No, the latter is bug. The MFP BASE is at 0x00fffa00L.
> 


No, the full 32 bit representation is valid for both ST and TT
and allowed AHCC to generate absolute addressing mode 7/0 (word)
The 68000 has only 24 address pins, so the MFP doesnt get to
see the excess.

> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Emutos-devel mailing list
> Emutos-devel@...
> https://lists.sourceforge.net/lists/listinfo/emutos-devel
> 


-- 
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Eero Tamminen wrote:

> Also, what's the issue here:
> -----------
> static void setvalue_snd(void)
> {
>   /* always at least a PSG */
>   cookie_snd = 1;
> 
> #if 0           /* HR: got a hang with this code */
>   /* Check for DMA sound */
>   if (check_read_byte(0xFFFF8903)) {
>     cookie_snd |= 2;
>   }
> #endif
> }
> -----------
> 

This is a issue in AHCC that I couldnt find within reasonable
time. It can be anything. Probably has to do with subtle
differences between AHCC and GCC.

It could as well be a bug in AHCC.
I'll have to spent more time as soon as I have some. :-)
Remember my attempts are only a proof of concept,
not a finished effort.

--
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger;  http://digger.atari.org
A Home Cooked C compiler:      AHCC;  http://ahcc.atari.org

Le 07/01/2010 20:44, Eero Tamminen a écrit :
> There was also something suspicious looking in "bios/atari_rootsec.h":
> ---------
> #if __AHCC__
> };
> #else
> } __attribute__ ((__packed__));
> #endif
> ---------
>
> Does AHCC make all structures packed (not padded) by default?
>
> When looking at the structure, I'm wondering about the need for the packed
> attribute thought.  All members are at least word aligned which, if I
> remember right, should be enough on 680x0.  Does GCC make 32-bit
> structure members 32-bit aligned by default for performance reasons?

The current m68k-atari-mint GCC aligns longs on 16-bit boundaries, so there 
is no need for __packed__. Furthermore __packed__ is evil on 68000, because 
it forces accesses to all short and longs using move.b and slow bitshifts !

Removed. Committed.

Furthermore, there was a second issue in bios/disk.c: the sect and sect2 
variables (using type struct rootsector*) were aliased to a byte array (byte 
array casted to struct rootsector*). So that was a second reason for GCC to 
access the short and longs using move.b !! I fixed that and double checked, 
now the longs in that structure are accessed using a move.l, as expected.

-- 
Vincent Rivière