Menu
▾
▴
#2 Hardware architecture independence
By using <stddef.h> and <inttypes.h>, integral types with specific bit-sizes can be selected. Thus, instead of declaring a variable to be 'int' and hoping that it is exactly 32 bits, one could declare a variable of type 'int32_t'.
I suggest this because you could then remove the architecture command-line argument from the makefile. The library could then be compiled on architectures other than Intel.
Logged In: NO
Thanks for the comment... will investigate and get back.
Logged In: YES
user_id=1051699
Originator: NO
Current integer types are the mostly widely used type in VTD-XML...
The simplest way would be to redefine int to be int32_t as
you suggested... my question to you is that
1. Can you name one platform that is less than 32-bit for int
2. If the platform uses 64-bit as int type, do you see any problems it may cause?
Logged In: YES
user_id=840096
Originator: YES
1. I can't name any desktop systems that currently use less than 32-bits for an int. However, I believe that there are still lots of embedded systems with word sizes less than 32 bits.
2. If the platform uses 64 bits for an int type, I believe that VTD-XML will still work, but obviously your space overhead will double.
I'm willing to create a branch, and modify the code to be more portable. However, I'm not willing to do the work if the work unless the work will be incoporated into the main repository.
If someone from the project is willing to merge the changes back into the repository, I'll make the changes. I don't expect that they'll be that much work.
Logged In: YES
user_id=1051699
Originator: NO
Yes, it would be a welcome addition to support embedded
devices. So please feel free to make modifications and
if it makes sense I don't see any reason why the change
is not merged into the main branch...
There is one more question: if the platform doesn't offer
the 32-bit integer type, and the amount of linear memory space
will be less than 2^32 ... then there is going to be changes
on the size of max XML message sizes as well...
maybe it is good to a fork of the code base to address those
platform specificly ?
Logged In: YES
user_id=840096
Originator: YES
Even if a platform does not use 32 bit words, the C compiler will still likely support a 32 bit integral type. On 32-bit systems, int32_t will simply be a typedef for int. However, on a 16 bit system, int32_t could be a typedef for long int. And, on 64-bit systems, int32_t could be a typedef for short int.
By using int32_t, we should be able to reach a fairly wide range of platforms. Changing the size of the VTD-XML records will lead to other changes in the bit-packing. I don't really feel comfortable commenting on how deep those changes would be.
In short, moving to int32_t instead of plain int should greatly expand the platforms that VTD-XML can be compiled for, with minimal effort.
Logged In: YES
user_id=1051699
Originator: NO
Currently VTD-XML in C has a full-version (supporting XPath)
and light version... it is probably a good idea to make incremental
changes to the light version, the biggest issue I see is the size
of the address space the platform can support, 2^16 may be a bit
too small.
Also do those platforms support unicode? What kind of C libs do
those platforms usually support (eg. ansi c, posix etc)??
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=840096
Originator: YES
I have made the changes to ximpleware_2.0_c_light.zip. I've run the code against a simple test on a Win2K machine and a Solaris 8 machine. The modified code is attached.
- The code now uses stdint.h and stdbool.h for integers of fixed sizes and booleans. These headers are not universally available, so there are two wrapper headers.
- I've pulled some definitions out of the header files and into the source files to limit visibility.
- The code does not depend on anything beyond the standard C library.
Please comment on the changes.
File Added: vtd-xml.zip
Logged In: YES
user_id=1051699
Originator: NO
ok will look into it and get back
Logged In: YES
user_id=840096
Originator: YES
I have made a few more changes to the code in ximpleware_2.0_c_light.zip. I've made a new ZIP file containing the updated code, which I've attached to this comment. There are some minor changes to (1) further improve const correctness and (2) move generic ints to more specific types.
However, the major change surrounds much of the code in vtdNav and vtdGen that creates and queries the 64-bit tokens. I've replaced the old code based on hard-coded masks. The new code uses several defines to specify the width and position in bits of the various fields (located in vtdNav.h). Evertything else is created automatically by the preprocessor. Note that the new code does not care about the endianess of the machine. This simplified many sections of code.
File Added: vtd-xml.zip
Updated code
Logged In: YES
user_id=1051699
Originator: NO
Thanks!
Still need a bit time to go over the code
Should release most of the enhancement in 2.1 version of the VTD-XML light...
the full version should absort most of the changes gradually...
Logged In: YES
user_id=1051699
Originator: NO
On a second thought, the changes seem substantial and require thorough debugging/testing...
I see your points in declaring masks and data types.. will absort those gradually into the main release for v 2.2
in the meantime, you are welcoome to join the VTD-XmL user discussion ...