Is m68k-linux the same as m68k-elf? about m68k_bare_metal HOT 5 CLOSED

Hi. Based on my understanding I don't think there would be any difference, since elf is just the format of the binary that is output at the end of the build, and I don't believe that changes anything to do with how the compiler treats integers.

Can you show an example of the code and/or any error messages that you are encountering difficulties with?

from m68k_bare_metal.

I was getting pointer to integer of different type conversions while using stdint.h when -mshort was specified (but not otherwise), as well as intermittent address exceptions for reads/writes to non-even addresses after I wrote the original post.

I found a script to help me install m68k-elf and that seems to have fixed both issues, even though both just produce an ELF binary. I didn't change anything but the compiler, and one worked while the other didn't.

(Note for anyone finding this later, the app "texinfo" is typo'd as "textinfo")

from m68k_bare_metal.

Ah ok.

According to this page: https://gcc.gnu.org/onlinedocs/gcc/M680x0-Options.html

-mshort
Consider type int to be 16 bits wide, like short int. Additionally, parameters passed on the stack are also aligned to a 16-bit boundary even on targets whose API mandates promotion to 32-bit.

Is there any particular reason to want the int type redefined as 16 bits instead of the typical 32?

I dont really know if that is a good or bad idea, but I guess it is application specific. My gut feeling is that "a lot of stuff could break", especially if it assumes that ints are 32 bits.

from m68k_bare_metal.

I read somewhere that without -mshort integers are lifted to 32 bits on the stack which I assume would negatively affect performance, at least on the original 68000.

from m68k_bare_metal.

Yeah, that is true. It will have an impact on performance because 32 bit values will require two reads/writes, but that's a bit unavoidable.

The performance hit is perhaps not quite as bad as it might seem though, only 50% for stack operations direct to/from a D register. Bytes and words require 8 clock cycles whereas longs require 12 (mostly).

If you don't already have it, download a document called MC68000UM.pdf from NXP. Section 8 has all of the instruction timings.

Personally, I think there are far greater negative implications from having ints sized at 16 bits than needing two reads/writes on some memory operations.

from m68k_bare_metal.