I am trying to print from a Xamarin.Forms application to Zebra ZQ220 mobile printer over bluetooth.
I installed Zebra.Printer.SDK version 2.15.2634 and i am able to print.
For Turkish character printing, i stored the font file SWISS721 in Zebra printer, and i am able to print Turkish characters via Zebra Setup Utilities / Open Communication With Printer / Direct Communication using my CPCL code, which is below.
! 0 200 200 500 1
PCX 0 1 !<NRPLOGO.PCX
T SWF12.CPF 0 125 180 şŞ iİ üÜ ğĞ öÖ çÇ
T SWF08.CPF 0 1 225 Tarih : 01.01.2022 Makbuz No : NTQ4NzIzNTM=
PRINT
In Xamarin.Forms application, according to Zebra documentation, i created a string to store CPCL like below:
private const string RealTestLabelCpclSwiss = "! 0 200 200 500 1\r\n"
+ "PCX 0 1 !<NRPLOGO.PCX\r\n"
+ "T SWF12.CPF 0 125 180 şŞ iİ üÜ ğĞ öÖ çÇ\r\n"
+ "T SWF08.CPF 0 1 225 Tarih : 01.01.2022 Makbuz No : NTQ4NzIzNTM=\r\n"
+ "PRINT\r\n";
To send this string to printer, this needs to be converted to a byte array, and Zebra documentation uses UTF8 encoding like below :
return Encoding.UTF8.GetBytes(RealTestLabelCpclSwiss);
I can print to printer but Turkish characters like şŞ İ Ğ are not printed correctly.
I assume this is an encoding issue, and i need to use maybe a different encoding, tried the encodings below:
return Encoding.Default.GetBytes(RealTestLabelCpclSwiss);
return Encoding.ASCII.GetBytes(RealTestLabelCpclSwiss);
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
return Encoding.GetEncoding(1254).GetBytes(RealTestLabelCpclSwiss);
return Encoding.GetEncoding("ISO-8859-9").GetBytes(RealTestLabelCpclSwiss);
But still i can't print Turkish characters with Xamarin.Forms.
My test device is an iPhone and i also checked the west checkbox in iOS project properties / iOS Build / Internationalization.
How can i correct this encoding issue with Xamarin.Forms ?
I resolved the issue. I used
Encoding.GetEncoding("iso-8859-9")
instead of
Encoding.GetEncoding("ISO-8859-9")
and i am able to print Turkish characters.
I didn't know this encoding name is case sensitive.
Could anyone please tell me is this the right model for non-deterministic values of integer and unsigned integer in Frama-C?
/* Suppose Frama-C is installed in /usr/local -default prefix */
#include "/usr/local/share/frama-c/builtin.h"
#include "/usr/local/share/frama-c/libc/limits.h"
...
#define nondet_int() Frama_C_interval(INT_MIN, INT_MAX)
#define nondet_uint() Frama_C_interval(0, UINT_MAX)
...
Are there any exceptions if I use the above code with different architectures in option -machdep?
No, in the Neon version you have to manually define the appropriate macro if you want to use another -machdep. You would typically end up with a command-line like that:
frama-c -cpp-extra-args="-D__FC_MACHDEP_X86_64" -machdep x86_64
Forthcoming Sodium release will make the -cpp-extra-args unnecessary, as well as providing by default a -I option to let preprocessor search into Frama-C's libc header, so that you won't have to provide it yourself or rely on absolute paths in your #include directive
NB: This answer is not a commitment to any particular date for the Sodium release.
One reason Frama_C_interval(0, UINT_MAX) may not work as intended is that Frama_C_interval has type int (int, int). When you happen to want the entire range of unsigned int values, that actually tends to help because the conversions that are introduced are subject to approximation, but in general the fact that Frama_C_interval is declared as returning an int is a nuisance.
The latest released version already has Frama_C_unsigned_int_interval, but it is in share/libc/__fc_builtin.h (installed to /usr/local/share/frama-c/libc/__fc_builtin.h. The file builtin.h looks like a vestigial remnant, especially with the $Id$ line dating back to when development was done under SVN.
For specifying that a value should be all possible unsigned intvalues, Frama_C_unsigned_int_interval(0, -1) saves yourself the trouble of including limit.h. The int value -1 passed as argument is converted to the largest unsigned int as per C rules.
I read that a 64-bit machine actually uses only 48 bits of address (specifically, I'm using Intel core i7).
I would expect that the extra 16 bits (bits 48-63) are irrelevant for the address, and would be ignored. But when I try to access such an address I got a signal EXC_BAD_ACCESS.
My code is:
int *p1 = &val;
int *p2 = (int *)((long)p1 | 1ll<<48);//set bit 48, which should be irrelevant
int v = *p2; //Here I receive a signal EXC_BAD_ACCESS.
Why this is so? Is there a way to use these 16 bits?
This could be used to build more cache-friendly linked list. Instead of using 8 bytes for next ptr, and 8 bytes for key (due to alignment restriction), the key could be embedded into the pointer.
The high order bits are reserved in case the address bus would be increased in the future, so you can't use it simply like that
The AMD64 architecture defines a 64-bit virtual address format, of which the low-order 48 bits are used in current implementations (...) The architecture definition allows this limit to be raised in future implementations to the full 64 bits, extending the virtual address space to 16 EB (264 bytes). This is compared to just 4 GB (232 bytes) for the x86.
http://en.wikipedia.org/wiki/X86-64#Architectural_features
More importantly, according to the same article [Emphasis mine]:
... in the first implementations of the architecture, only the least significant 48 bits of a virtual address would actually be used in address translation (page table lookup). Further, bits 48 through 63 of any virtual address must be copies of bit 47 (in a manner akin to sign extension), or the processor will raise an exception. Addresses complying with this rule are referred to as "canonical form."
As the CPU will check the high bits even if they're unused, they're not really "irrelevant". You need to make sure that the address is canonical before using the pointer. Some other 64-bit architectures like ARM64 have the option to ignore the high bits, therefore you can store data in pointers much more easily.
That said, in x86_64 you're still free to use the high 16 bits if needed (if the virtual address is not wider than 48 bits, see below), but you have to check and fix the pointer value by sign-extending it before dereferencing.
Note that casting the pointer value to long is not the correct way to do because long is not guaranteed to be wide enough to store pointers. You need to use uintptr_t or intptr_t.
int *p1 = &val; // original pointer
uint8_t data = ...;
const uintptr_t MASK = ~(1ULL << 48);
// === Store data into the pointer ===
// Note: To be on the safe side and future-proof (because future implementations
// can increase the number of significant bits in the pointer), we should
// store values from the most significant bits down to the lower ones
int *p2 = (int *)(((uintptr_t)p1 & MASK) | (data << 56));
// === Get the data stored in the pointer ===
data = (uintptr_t)p2 >> 56;
// === Deference the pointer ===
// Sign extend first to make the pointer canonical
// Note: Technically this is implementation defined. You may want a more
// standard-compliant way to sign-extend the value
intptr_t p3 = ((intptr_t)p2 << 16) >> 16;
val = *(int*)p3;
WebKit's JavaScriptCore and Mozilla's SpiderMonkey engine as well as LuaJIT use this in the nan-boxing technique. If the value is NaN, the low 48-bits will store the pointer to the object with the high 16 bits serve as tag bits, otherwise it's a double value.
Previously Linux also uses the 63rd bit of the GS base address to indicate whether the value was written by the kernel
In reality you can usually use the 48th bit, too. Because most modern 64-bit OSes split kernel and user space in half, so bit 47 is always zero and you have 17 top bits free for use
You can also use the lower bits to store data. It's called a tagged pointer. If int is 4-byte aligned then the 2 low bits are always 0 and you can use them like in 32-bit architectures. For 64-bit values you can use the 3 low bits because they're already 8-byte aligned. Again you also need to clear those bits before dereferencing.
int *p1 = &val; // the pointer we want to store the value into
int tag = 1;
const uintptr_t MASK = ~0x03ULL;
// === Store the tag ===
int *p2 = (int *)(((uintptr_t)p1 & MASK) | tag);
// === Get the tag ===
tag = (uintptr_t)p2 & 0x03;
// === Get the referenced data ===
// Clear the 2 tag bits before using the pointer
intptr_t p3 = (uintptr_t)p2 & MASK;
val = *(int*)p3;
One famous user of this is the V8 engine with SMI (small integer) optimization. The lowest bit in the address will serve as a tag for type:
if it's 1, the value is a pointer to the real data (objects, floats or bigger integers). The next higher bit (w) indicates that the pointer is weak or strong. Just clear the tag bits and dereference it
if it's 0, it's a small integer. In 32-bit V8 or 64-bit V8 with pointer compression it's a 31-bit int, do a signed right shift by 1 to restore the value; in 64-bit V8 without pointer compression it's a 32-bit int in the upper half
32-bit V8
|----- 32 bits -----|
Pointer: |_____address_____w1|
Smi: |___int31_value____0|
64-bit V8
|----- 32 bits -----|----- 32 bits -----|
Pointer: |________________address______________w1|
Smi: |____int32_value____|0000000000000000000|
https://v8.dev/blog/pointer-compression
So as commented below, Intel has published PML5 which provides a 57-bit virtual address space, if you're on such a system you can only use 7 high bits
You can still use some work around to get more free bits though. First you can try to use a 32-bit pointer in 64-bit OSes. In Linux if x32abi is allowed then pointers are only 32-bit long. In Windows just clear the /LARGEADDRESSAWARE flag and pointers now have only 32 significant bits and you can use the upper 32 bits for your purpose. See How to detect X32 on Windows?. Another way is to use some pointer compression tricks: How does the compressed pointer implementation in V8 differ from JVM's compressed Oops?
You can further get more bits by requesting the OS to allocate memory only in the low region. For example if you can ensure that your application never uses more than 64MB of memory then you need only a 26-bit address. And if all the allocations are 32-byte aligned then you have 5 more bits to use, which means you can store 64 - 21 = 43 bits of information in the pointer!
I guess ZGC is one example of this. It uses only 42 bits for addressing which allows for 242 bytes = 4 × 240 bytes = 4 TB
ZGC therefore just reserves 16TB of address space (but not actually uses all of this memory) starting at address 4TB.
A first look into ZGC
It uses the bits in the pointer like this:
6 4 4 4 4 4 0
3 7 6 5 2 1 0
+-------------------+-+----+-----------------------------------------------+
|00000000 00000000 0|0|1111|11 11111111 11111111 11111111 11111111 11111111|
+-------------------+-+----+-----------------------------------------------+
| | | |
| | | * 41-0 Object Offset (42-bits, 4TB address space)
| | |
| | * 45-42 Metadata Bits (4-bits) 0001 = Marked0
| | 0010 = Marked1
| | 0100 = Remapped
| | 1000 = Finalizable
| |
| * 46-46 Unused (1-bit, always zero)
|
* 63-47 Fixed (17-bits, always zero)
For more information on how to do that see
Allocating Memory Within A 2GB Range
How can I ensure that the virtual memory address allocated by VirtualAlloc is between 2-4GB
Allocate at low memory address
How to malloc in address range > 4 GiB
Custom heap/memory allocation ranges
Side note: Using linked list for cases with tiny key values compared to the pointers is a huge memory waste, and it's also slower due to bad cache locality. In fact you shouldn't use linked list in most real life problems
Bjarne Stroustrup says we must avoid linked lists
Why you should never, ever, EVER use linked-list in your code again
Number crunching: Why you should never, ever, EVER use linked-list in your code again
Bjarne Stroustrup: Why you should avoid Linked Lists
Are lists evil?—Bjarne Stroustrup
A standards-compliant way to canonicalize AMD/Intel x64 pointers (based on the current documentation of canonical pointers and 48-bit addressing) is
int *p2 = (int *)(((uintptr_t)p1 & ((1ull << 48) - 1)) |
~(((uintptr_t)p1 & (1ull << 47)) - 1));
This first clears the upper 16 bits of the pointer. Then, if bit 47 is 1, this sets bits 47 through 63, but if bit 47 is 0, this does a logical OR with the value 0 (no change).
I guess no-one mentioned possible use of bit fields ( https://en.cppreference.com/w/cpp/language/bit_field ) in this context, e.g.
template<typename T>
struct My64Ptr
{
signed long long ptr : 48; // as per phuclv's comment, we need the type to be signed to be sign extended
unsigned long long ch : 8; // ...and, what's more, as Peter Cordes pointed out, it's better to mark signedness of bit field explicitly (before C++14)
unsigned long long b1 : 1; // Additionally, as Peter found out, types can differ by sign and it doesn't mean the beginning of another bit field (MSVC is particularly strict about it: other type == new bit field)
unsigned long long b2 : 1;
unsigned long long b3 : 1;
unsigned long long still5bitsLeft : 5;
inline My64Ptr(T* ptr) : ptr((long long) ptr)
{
}
inline operator T*()
{
return (T*) ptr;
}
inline T* operator->()
{
return (T*)ptr;
}
};
My64Ptr<const char> ptr ("abcdefg");
ptr.ch = 'Z';
ptr.b1 = true;
ptr.still5bitsLeft = 23;
std::cout << ptr << ", char=" << char(ptr.ch) << ", byte1=" << ptr.b1 <<
", 5bitsLeft=" << ptr.still5bitsLeft << " ...BTW: sizeof(ptr)=" << sizeof(ptr);
// The output is: abcdefg, char=Z, byte1=1, 5bitsLeft=23 ...BTW: sizeof(ptr)=8
// With all signed long long fields, the output would be: abcdefg, char=Z, byte1=-1, 5bitsLeft=-9 ...BTW: sizeof(ptr)=8
I think it may be quite a convenient way to try to make use of these 16 bits, if we really want to save some memory. All the bitwise (& and |) operations and cast to full 64-bit pointer are done by compiler (though, of course, executed in run time).
According to the Intel Manuals (volume 1, section 3.3.7.1) linear addresses has to be in the canonical form. This means that indeed only 48 bits are used and the extra 16 bits are sign extended. Moreover, the implementation is required to check whether an address is in that form and if it is not generate an exception. That's why there is no way to use those additional 16 bits.
The reason why it is done in such way is quite simple. Currently 48-bit virtual address space is more than enough (and because of the CPU production cost there is no point in making it larger) but undoubtedly in the future the additional bits will be needed. If applications/kernels were to use them for their own purposes compatibility problems will arise and that's what CPU vendors want to avoid.
Physical memory is 48 bit addressed. That's enough to address a lot of RAM. However between your program running on the CPU core and the RAM is the memory management unit, part of the CPU. Your program is addressing virtual memory, and the MMU is responsible for translating between virtual addresses and physical addresses. The virtual addresses are 64 bit.
The value of a virtual address tells you nothing about the corresponding physical address. Indeed, because of how virtual memory systems work there's no guarantee that the corresponding physical address will be the same moment to moment. And if you get creative with mmap() you can make two or more virtual addresses point at the same physical address (wherever that happens to be). If you then write to any of those virtual addresses you're actually writing to just one physical address (wherever that happens to be). This sort of trick is quite useful in signal processing.
Thus when you tamper with the 48th bit of your pointer (which is pointing at a virtual address) the MMU can't find that new address in the table of memory allocated to your program by the OS (or by yourself using malloc()). It raises an interrupt in protest, the OS catches that and terminates your program with the signal you mention.
If you want to know more I suggest you Google "modern computer architecture" and do some reading about the hardware that underpins your program.
Version numbers are needed all over a project; in installers, code, toolchains etc. I despise duplication. I want my version numbers to be stored in one central authoritative location.
I am working with C/C++ and using Qt on various platforms. In Qt, qmake projects specify version numbers like:
VERSION = 1.2.3
In code I use something like in a header like Version.h:
#define VERSION_MAJ 1
#define VERSION_MIN 2
#define VERSION_REV 3
#define VERSION_STRING \"VERSION_MAJ\" "." \"VERSION_MIN\" "." \"VERSION_REV\"
My installer toolchain has support for C preprocessing so I can use the same version specified in Version.h. However, I don't know how to get qmake to use the same version number. I thought I could preprocess the pro file, but that won't work as # characters mean a comment in pro files and the C preprocessor will fall over.
Anyone know of a good way to keep my version number centralised?
I use something like this in my build system
#.pro file
#Application version
VERSION_MAJOR = 1
VERSION_MINOR = 0
VERSION_BUILD = 0
DEFINES += "VERSION_MAJOR=$$VERSION_MAJOR"\
"VERSION_MINOR=$$VERSION_MINOR"\
"VERSION_BUILD=$$VERSION_BUILD"
#Target version
VERSION = $${VERSION_MAJOR}.$${VERSION_MINOR}.$${VERSION_BUILD}
And after that you can use VERSION_MAJOR and others as normal macro in your application.
If you want to be able to store your version numbers in a c header file, you can do so and then import them into the Qt project variables in the project file. Something like the below should work:
Version.h:
#define MY_MAJOR_VERSION 3
#define MY_MINOR_VERSION 1
.pro
HEADERS += Version.h
VERSION_MAJOR = MY_MAJOR_VERSION
VERSION_MINOR = MY_MINOR_VERSION
The advantage of doing it this way round is that you can then use your authoritative header file if you need to compile other parts of the project away from Qt.
I am not sure if this is the right stack exchange website to post this on, but if it isn't please move it to the appropriate one.
I am facing a small problem in writing my constraints file for the spartan 3 starter kit.
I have read the documentation provided by Xilinx (the manufacturer) and ive been searching online for a few weeks without any luck.
What i am trying to do is link my Netlist interface to any of the 3 40-pin-headers on the board. (See image below)
Usually its very simple, if say i want to interface a button or a led on the board, i just read the connection name on the board, for example one of the buttons is M13 and write in the UCF file something like this :
NET "BTN0" LOC = "M13";
As you can see on the image the headers are named A1, A2 and B1 on the board, but oddly enough, none of the following worked :
NET "TestOutputLine" LOC = "A1(0)"; -- The (0) is to reference a single line on an array
NET "TestOutputBus" LOC = "A1"; -- The bus is of equal dimension of A1 (which is 40)
The errors i got meant that either the target (specified by LOC) does not exist or that the assignment is invalid.
I hope you have some ideas for me.
Thanks in advance
EDIT :
Here is the output from ISE :
ConstraintSystem:59 - Constraint <NET "TestOutputBus" LOC = "A1";>
[circuit.ucf(12)]: NET "TestOutputBus" not found. Please verify that:
1. The specified design element actually exists in the original design.
But i am pretty sure that TestOutputBus exists, as a matter of fact there is nothing else in my design right now, and the correct top level unit is being used.
EDIT2 :
I updated my UCF file, right now it's like this :
NET "TestOutputBus(0)" LOC = "A1(0)";
NET "TestOutputBus(1)" LOC = "A1(1)";
But i get a different error now in mapping :
MapLib:30 - LOC constraint A1:0 on TestOutputBus<0> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
MapLib:30 - LOC constraint A1:1 on TestOutputBus<1> is invalid: No such
site on the device. To bypass this error set the environment variable
'XIL_MAP_LOCWARN'.
Solution :
In order to get the pins 5 and 6 mapped to TestOutputBus(0) and TestOutputBus(1) respectively what i had to use was this :
NET "TestOutputBus(0)" LOC = "N7"; -- A1 pin 5
NET "TestOutputBus(1)" LOC = "L5"; -- A1 pin 6
Note that pins 0 are not mappable thats why i used pins 5 and 6, here are the tables that show the mappable pins for all headers and their LOCs.
As it turns out, there is an address for each usable pin of each header of the FPGA.
The datasheet (http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/3411/1/S3BOARD_RM.pdf) was helpful especially pages 49 - 51
I copied this from my earlier comment to your question so it would be an actual answer and not just a comment.
You should have LOC constraints in your UCF file for every port on your top-level module. So if you have a 40-bit-wide bus as an input or output at the top level then you should also have 40 separate LOC constraints in your UCF file to make sure that the logical bus in your top-level schematic actually gets mapped to the correct pins on your FPGA. If you are only using two pins, then you can declare the bus to be 2-bits wide and use 2 LOC constraints. The FPGA will treat all unused pins as inputs and ignore them.
I once got the original ConstraintSystem:59 net xyz not found error when i accidentally selected one of my modules as a top module. The pins declared in UCF could not be found in the port declaration of wrong module.
Also i get this error when i have some pin declared in UCF but ommit it in port declaration of top module.