I'm programming a c# dll to parse messages from a NX 584 Module.
I'm new to binary messages and I'm stuck with the following message:
I'm having trouble understanding the location part.
The logical location is 12 bits long, but an IP address is 4 bytes long. So I don't get how the fit an IP address in 12 bits.
What should I do with the segment size and offset?
Also, what is meant with number of segments?
Any help would be appreciated, thanks.
Disclaimer: I know absolutely nothing about NX 584, but skimming through the documentation suggested that "logical location" isn't an IP address, but some kind of storage/RAM address.
12 bits would therefore seem to be the address bus size of this thing.
Related
OK, I've used the Linux Dwarf ldw library to convert backtrace_symbols output to source code and line numbers but I've hit a snag. backtrace_symbols gives offsets in memory from which I subtract the base address (obtained using dladdr()) before using as input into Dwarf. But it seems that for the parent executable, I should NOT subtract the base address because the Dwarf offsets seem to include it.
So how do I either distinguish between EXE and SO in my code (I'm hoping there's something better than 'look for ending .so') or is there a different function I can call that will obtain the base address or zero for the parent EXE?
Yes, you are right. If the executable is a ET_EXEC (not a DT_DYN i.e. it is not a position-independant executable), then the virtual addresses in the DWARF are the real virtual addresses in your program image. For DT_DYN the addresses in the DWARF are offsets from the base address of the module.
This is explained in 7.3 of the DWARF spec:
The relocated addresses in the debugging informations for an executable
object are virtual addresses and the relocated addresses in the
debugging informations for a shared object are offsets relative
to the start of the lowest region of memory loaded from that
shared memory.
You should use e_type in the ELF header to distinguish them.
No sure if this is the best way, but ldw has a function, dwarf_getelf(), that can get you to the ELF information, from there use elf32/64_getehdr() and from there look at the e_type field. If e_type is ET_DYN then it's a shared object and you should carry on and use dladdr to find the offset to delete from addresses else just use the addresses generated by backtrace directly.
I'm working on storing a JSON snippet onto a type 31 QR Code so that I can scan it with a smartphone and parse the JSON.
I'm running into a few challenges..
A type 31 QR Code is the "densest" (for lack of better words) code that I can get my Android device to reliably scan. This can store 2677 Alphanumeric characters factoring in 7% error correction.
What are my options for compressing my optimized/minified JSON object and encoding a QR code with it? Conceivably, how much more data can I store? Or am I even barking up the right tree?
It all depends, really.
Is Wi-Fi available? If so, put your JSON snippets on a web server and encode their URLs in the QR codes. Problem solved.
If this is for general consumption, then you need to be aware that some phones are better than others. Mine really struggled to scan a version 25 QR code. I'd consider anything higher than version 20 as unreliable.
There's little benefit in using the alphanumeric mode. It only stores uppercase letters, digits 0-9 and a handful of punctuation marks. At 5½ bits per character (11 bits per pair), its storage capacity is almost identical to the corresponding binary mode (8 bits per character).
In a quick test gzip -n -9 reduced a 545-byte JSON file to 219 bytes (40% of the original size). You could do a lot better than this if you stored your data in a compact binary format instead of a verbose tagged format.
If you're putting these QR codes out in public, you'll need to include some sort of authentication mechanism (e.g., a 32-bit checksum) to prevent malicious code injections and other tomfoolery.
I have been given a simple ISA with two registers.
opcode: 2 bits, register1: 3 bits, register2: 3 bits.
It is asking me to find the size of the register file, how many registers can be addressed, and If each register’s size is the same that the instruction’s size, what is the size of the memory in bytes?
I am not asking for the exact answers, but i really can't find anywhere online or in my notes saying how to determine a register file's size given what i've been given.
Can anyone point me in the right direction?
Thanks
It is asking me to find the size of the register file, how many registers can be addressed
If the instruction encodes register operands with X bits, that gives 2^X possible registers that the instruction can address.
and If each register’s size is the same that the instruction’s size, what is the size of the memory in bytes?
That question seems incomplete to me since the answer depends on which addressing modes the ISA provides. If we assume that only register-indirect memory access is allowed (e.g. ld r0,(r1)) with no scaling we end up with 2^InstructionWidth bytes of addressable memory.
I am reading the book 'Computer Organization and Design' by Patterson and Hennessy and got interested in MIPS.
I have doubts in finding the range of a jump/branch instruction. Also in determining the number of branch/jump instructions required to get to a specific address.
Can someone provide an explanation of how this has to be calculated i.e. Considering PC at a specific address and finding the number of branch/jump instructions needed to go to a different address? For example, what if PC is at 0x10001010, what is the range of addresses of branch and jump instructions?
Or can you direct me to some online resource or book which would help me in getting a better understanding of these?
The following is all for MIPS-32.
Branch B, BEQ, BNE, etc. instructions have a 16 bit signed word offset field, allowing a branch to an address +/- 128kBytes from the current location. A jump J instruction specifies an address within the current 256MByte region specified by PC's most significant 4 bits : 26<<2 bits(this is not a relative address). To branch to an arbitrary address anywhere in the 4GB address space, use JR (jump register) which jumps to an address contained in a general purpose register.
It takes either a single branch or jump instruction, or a register load followed by a JR to jump to an arbitrary address, depending how far away the address is.
The best book for MIPS programming is still See MIPS Run. You can also find MIPS architecture reference manuals at mips.com (registration required). The most relevant document is MIPS32® Architecture for Programmers Volume II: The MIPS32® Instruction Set.
My application runs well on HTC HD2 which has Qualcomm 1GHz Snapdragon processor but when try to run on Windows professional emulator 6 or PIDION which has ARM processor, it crashes with datatype misalignment exception.
Can anyone please help me out to find why it crashes and how to resolve it.
According to this link, __unaligned should solve the crash but did not work in my case.
__unaligned isn't a magic bullet that you should simply start throwing around when you get a misalignment exception. First you have to determine where in the code that exception occurred and then look at why. Are you accessing a pointer that is misaligned? Something like taking a byte array or buffer of some sort and then trying to accedd WORD data from an odd boundary or DWORD data from an address not divisible by 4?
BYTE buffer[256];
....
DWORD d = *(DWORD*)buffer[3];
Or maybe you have a structure that you have strange packing on?
#pragma pack(push, 1)
struct
{
BYTE b;
DWORD d;
} s;
#pragma pack(pop)
The key is that you must make aligned accesses. x86 allows you to make unaligned accesses only because it catches the exception for you then does a second, unaligned read. Here's a quick tutorial, though bear in mind this is for x86, so it shows the CPU "fixing" the misalignment for you. ARM is not so forgiving. You must rearrange or reassembly the data yourself on ARM.
You likely have to do a memcpy to an aligned address and use the data from there, but without knowing anything about your code, it's impossible to give much more insight.