2

There is an assembler that I am writing that is located within the file asm.c located in this repository. It uses the instruction set located in the specs file to produce an output binary. (The program that would run this binary has not yet been made - the beginning is located in main.c.) Using the example program named echochar.sdmasm, the assembler outputs the desired binary. Here it is in hex:

90 00 a0 00

But it only does this so far on a Windows machine under Cygwin. (I have not yet tested it under Linux.) On an Intel-based Mac, this is the resultant binary:

00 90 00 a0

This looks like a difference in endianness, but I thought that this could only happen when two processors are completely different. This seems to be and endian difference between operating systems, not processors. Is this really the case, or is something else going on here that I am not getting?

Just managed to test it on Linux - the output error occurs as it does on the Mac.

Okay, something else is going on entirely. Output from hd on Linux:

00000000  00 90 00 a0                                       |....|
00000004

Output from hexdump on Linux:

0000000 9000 a000                              
0000004

This is really odd. I can't tell which one is the correct output.

Robert Harvey
  • 200,592
LordCreepity
  • 45

2 Answers2

2

Something else is going on, likely a bug in the code.

It looks like an off-by-one error to me, not an endianness change.

Check your type widths and your bit shifts.

Lightness Races in Orbit
  • 8,775
0

Given your expected output as shown above (i.e. 90 00 etc), your code is incorrect - it assumes it is running on a big-endian machine. I would suggest either changing your fwrite to a couple of fputc calls, or alternatively assembling your instructions byte-by-byte in an array of uint8_t.

As to the discrepancies of output, it seems some of the viewer programs you are using are reading 16-bit words in little-endian mode and others are reading byte-by-byte, thus the discrepancy. This is made more confusing by the fact that your output is not what you expect, probably causing you to look in the wrong place for the issue.

Jules
  • 17,880
  • 2
  • 38
  • 65