View unanswered posts | View active topics It is currently Tue Sep 17, 2019 6:57 am



Reply to topic  [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5
 One Page Computing - roll your own challenge 
Author Message

Joined: Sat Jun 16, 2018 2:51 am
Posts: 41
Thanks for the responses!

Would it be big endian if the bytes were packed as follows?
Code:
0000: 0100                  GLOBAL1:        BYTE    0x01
0001: 0102                  GLOBAL2:        BYTE    0x01, 0x02
0002: 0102 0300             GLOBAL3:        BYTE    0x01, 0x02, 0x03
0004: 0102 0304             GLOBAL4:        BYTE    0x01, 0x02, 0x03, 0x04


Is there a reason to use one approach over the other? At first glance, it seems little endian is popular only because of legacy.

For the programmer, using the BYTE directive with little endian seems confusing as what they define will be stored in memory swapped... For example suppose they wanted to access the fourth byte (0x04) in GLOBAL4. The programmer would have to realize that the byte is actually stored at GLOBAL4 + 2 bytes instead of GLOBAL4 + 3 bytes.

This is further confusing because for byte strings, the bytes are stored in the order in which they appear... For example:
Code:
BYTE "Hello", 0x0a
is stored as 0x4865 0x6c6c 0x6f0a. ('H'-0x48, 'e'-0x65, 'l'-0x6c, 'o'-0x6f)

Tangentially related, how would a C compiler for OPC6 translate a data type like char (1 byte)? Would it use the BYTE directive of the assembler?


Last edited by quadrant on Wed Mar 20, 2019 9:09 pm, edited 3 times in total.



Wed Mar 20, 2019 8:10 pm
Profile

Joined: Sat Jun 16, 2018 2:51 am
Posts: 41
BigEd wrote:
And we do read and interpret srecords, I think, and had to decide how to handle a bytestream. I expect that was a little-endian approach too.
What are srecord files used for? Also how does the OPC get access to one, do you transmit it over serial (rx/tx) to a physical OPC (ex hosted on an FPGA)?

There seems to be quite a bit of stuff hidden away in the libraries (one, two)...


Wed Mar 20, 2019 8:32 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1255
For sure, arguments have raged elsewhere over whether little or big endian is the more natural. Suffice it to say, I find little endian more natural - not a question of legacy!

For some of the OPC machines, hoglet wrote a small monitor program, which allowed us to load code, and IIRC it was in srecord format. It's possible I misremember. And yes, ultimately the srecord data would have come from a host, over a serial line. We have had OPCs connected up as second processor to a BBC Micro (or Master), and we've done that in both FPGA form and in emulated-on-a-Pi form. In that configuration, I often connect a serial cable to the Beeb, and drive it from a laptop. It's quite convenient to paste data in srecord format when I've done that. But I can't be completely sure this is what I did. I now remember we also had an OPC on a BlackICE FPGA board, which has a USB port that acts as a serial device.


Wed Mar 20, 2019 8:37 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1255
Ah, just noticed, you have already found and linked to some srecord-reading code for OPC!


Wed Mar 20, 2019 8:38 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1255
quadrant wrote:
Tangentially related, how would a C compiler for OPC6 translate a data type like char (1 byte)? Would it use the BYTE directive of the assembler?

I think there are choices here, but making a char 16 bits might be most natural. It does potentially waste space.
This article is a fun read:


Wed Mar 20, 2019 8:44 pm
Profile

Joined: Sat Jun 16, 2018 2:51 am
Posts: 41
Ah I see. I've seen the photo, but must admit didn't really understand what was happening.

Thanks for the article link, will give it a read.


Wed Mar 20, 2019 10:06 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1255
Sorry about my vagueness. There are two setups we've used: a standalone OPC computer with a monitor program, and an OPC as a second processor connected to a Beeb. And in the second case, that's been either an FPGA or a Pi running a C model. So, three setups. I'll come in again...


Wed Mar 20, 2019 10:19 pm
Profile

Joined: Tue Apr 25, 2017 7:33 pm
Posts: 26
quadrant wrote:
This is further confusing because for byte strings, the bytes are stored in the order in which they appear... For example:
Code:
BYTE "Hello", 0x0a
is stored as 0x4865 0x6c6c 0x6f0a. ('H'-0x48, 'e'-0x65, 'l'-0x6c, 'o'-0x6f)


I'm not sure there's any confusion here if you run the assembler. The code in your snippet above isn't valid syntax - it doesn't work, and certainly doesn't end up with bytes stored in that order.

This is the output of the assembler.

Code:
0000  0000 0000 0000        BYTE    "HELLO", 0x0A

Assembled 3 words of code with 1 error and 0 warnings.

Symbol Table:

PC                               0x0001 (000001)

Error: illegal or undefined register name or expression in ...
         BYTE    "HELLO", 0x00


I think what you meant to write was

Code:
0000  4548 4c4c 0a4f        BSTRING    "HELLO", 0x0A

Assembled 3 words of code with 0 errors and 0 warnings.


..which as you can see stores the bytes in the same little endian order as if they had been specified using the BYTE directive. So BSTRING and BYTE are consistent with each other.

If you prefer to store characters one per 16-bit word, then use either the STRING or WORD directive. There are also PSTRING and PBSTRING options for Pascal style strings with either word or byte storage respectively.


Wed Mar 20, 2019 10:24 pm
Profile

Joined: Sat Jun 16, 2018 2:51 am
Posts: 41
I guess my confusion arises from the discussion in the link I shared where they are talking about how a compiled C program stores a string in memory.
Quote:
ANSI C standard 6.1.4 specifies that string literals are stored in memory by "concatenating" the characters in the literal.
This can be confirmed by writing a simple C program and viewing the generated binary.* I incorrectly assumed that OPC6 follows this convention when handling strings. I have a feeling I'm getting confused by the byte order used in a high level language vs what the machine actually does at the low level.

*Edit:
Do debuggers swap the bytes accordingly? For example when you are viewing a hexdump? Above when I state viewing the binary, I used the program objdump. But it seems that objdump knows the endianness of the binary it is displaying...
Quote:
--endian={big|little}
Specify the endianness of the object files. This only affects
disassembly. This can be useful when disassembling a file format
which does not describe endianness information, such as
S-records.
Also, I do not want to hijack this thread with my confusion on endianess. I will gladly move it if necessary.


Edit 2:
I came across this post (Does hexdump respect the endianness of its system).

I ran the following on my terminal:
Code:
$ echo Hello > endianTest.txt

$ hexdump endianTest.txt
0000000 6548 6c6c 0a6f
0000006

$ hexdump -C endianTest.txt
00000000  48 65 6c 6c 6f 0a                        |Hello.|
00000006

$ hexdump -c endianTest.txt
0000000   H   e   l   l   o  \n
0000006
And the man pages for hexdump say the following about the -C and -c flags:
Quote:
-C
Canonical hex+ASCII display. Display the input offset in hexadecimal,
followed by sixteen space-separated, two column, hexadecimal bytes,
followed by the same sixteen bytes in %_p format
enclosed in ``|'' characters.
-c
One-byte character display. Display the input offset in hexadecimal,
followed by sixteen space-separated, three column, space-filled,
characters of input data per line.
So I got confused with what I was reading from my debugging tool as it likely uses the hex+ASCII display. Even though my machine is little endian and stored the string bytes accordingly, they were displayed as big endian.

Edit 3 (last):
This directly answered my question. String is stored as it appears. If hexdump reads two bytes integers (default behaviour) it will display the bytes of the pair swapped in accordance with little endian. If hexdump reads one byte integers (for example with -c and -C flags) it will display them in order appear in file.
Quote:
-x
Two-byte hexadecimal display. Display the input offset in hexadecimal,
followed by eight, space separated, four column, zero-filled,
two-byte quantities of input data, in hexadecimal, per line.


Last edited by quadrant on Thu Mar 21, 2019 8:44 pm, edited 1 time in total.



Wed Mar 20, 2019 11:47 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1255
I think a thread on endianness might well be the right answer here.

Mostly, a word-oriented machine doesn't even have the concept of endianness - that can only arise in software running on the machine, which can do whatever it likes, or software running off the machine, as in the case of the assembler, which is similarly unconstrained. When machines have both addressable words and addressable bytes, there's then the question of presentation. Every debugger and hex dumper has the option of "helping" by presenting data in some particular way. It's easy to be misled if your only view of memory is coming from a "helpful" tool!


Thu Mar 21, 2019 8:03 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5

Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software