we are using the OpenVMS C-Compiler (V6.2) with the option
/names=shortened
For some automatic code generation (for combining Pascal and Java code) we
would need the algorithm of the C-Compiler that is used for computing the
7-character CRC
e.g.
Java_at_pke_sms_comlayer_SmsInvoker_generateEvent
is shortened by the compiler to
Java_at_pke_sms_comlaye1gtr1n9$
Is it possible (preferably in Java) to compute the
1gtr1n9
checksum outside the C compiler ?
Thanks in advance.
Walter Kuhn
I would recommend approaching this from a different angle.
What is the method that Java is using to access the code compiled in C?
Can you use the /FIRST_INCLUDE= qualifier on the C compiler to include a
header file that uses #define long_symbol_name shr_sym_nm to force the
names generated by the compiler to ones that you control?
-John
malm...@dskwld.zko.dec.compaq.hp
Personal Opinion Only
Java accesses native methods in a way that (to keep the example) a method of package
at.pke.sms.comlayer
in class
SmsInvoker
called
generateEvent
must be declared as
Java_at_pke_sms_comlayer_SmsInvoker_generateEvent
This is exactly how the javah-Tool of the JDK works.
Implementation e.g. in Pascal looks like this :
[GLOBAL ("Java_at_pke_sms_comlaye1gtr1n9$"),
ASYNCHRONOUS,UNBOUND]
PROCEDURE LSSCL$WSM$GenerateEvent
In my opinion using #define would cause the JVM to fail when calling the native method.
Regards
Walter
Kuhn
> Implementation e.g. in Pascal looks like this :
>
> [GLOBAL ("Java_at_pke_sms_comlaye1gtr1n9$"),
> ASYNCHRONOUS,UNBOUND]
> PROCEDURE LSSCL$WSM$GenerateEvent
The C code to do the same is:
#define Java_at_pke_sms_comlaye1gtr1n9$ LSSCL$WSM$GenerateEvent
If I understand you, the issue is that you do not know what global
symbol that the JVM is really expecting so that you can code your
Pascal definition module.
The following link sould help you:
http://h18012.www1.hp.com/java/faq/ovms.html#4.1b
It provides a link to a tool that your automated procedure may be able
to be adapted to use.
-John
malm...@dskwld.zko.dec.compaq.com
Personal Opinion Only
>> Implementation e.g. in Pascal looks like this :
>>
>> [GLOBAL ("Java_at_pke_sms_comlaye1gtr1n9$"),
>> ASYNCHRONOUS,UNBOUND]
>> PROCEDURE LSSCL$WSM$GenerateEvent
>
>
> The C code to do the same is:
>
> #define Java_at_pke_sms_comlaye1gtr1n9$ LSSCL$WSM$GenerateEvent
>
You would need to use /NAMES=AS_IS to get the same behavior in C I believe.
That Pascal syntax (the quoted string with the GLOBAL attribute) uses
that string AS-IS for the global symbol name. The #define macro
substitution won't change C's default behavior for case handling for
linker visible names.
--
John Reagan
HP Pascal/{A|I}MACRO for OpenVMS Project Leader
Hewlett-Packard Company
Re-reading the original question, you want to know how to compute the
same CRC that the C compiler computes automatically, right?
I don't see that documented anywhere in the C manuals.
I thought the CRC calculation is a published standard.
Google gave me this link and more:
http://www.lammertbies.nl/comm/info/crc-calculation.html
yes, exactly, how to compute the CRC!
Walter
"John Reagan" <john....@hp.com> schrieb im Newsbeitrag
news:zb9Ie.9809$xx5....@news.cpqcorp.net...
John Malmberg wrote on August 3rd:
>
> The following link should help you:
We generate the CRC by calling lib$crc as follows:
long initial_crc = -1;
crc_result = lib$crc(good_crc_table,
&initial_crc,
<descriptor of string to CRC>);
where good_crc_table is:
/*
** Default CRC table:
**
** This table was taken from Ada's generalized name generation
** algorithm. It represents a commonly used CRC polynomial known
** as AUTODIN-II. For more information see the VAX Macro VMS
** documentation under the CRC VAX instruction.
*/
static const unsigned int good_crc_table[16] =
{0x00000000, 0x1DB71064, 0x3B6E20C8, 0x26D930AC,
0x76DC4190, 0x6B6B51F4, 0x4DB26158, 0x5005713C,
0xEDB88320, 0xF00F9344, 0xD6D6A3E8, 0xCB61B38C,
0x9B64C2B0, 0x86D3D2D4, 0xA00AE278, 0xBDBDF21C};
Hope this helps...sorry for the small type...I can't figure out
how to cut/paste any other way!!
Ed Vogel
HP/Compaq/DEC C/C++ Engineering.
libxml2 has an example of what I think you are doing -- I've
ported 2.6.20 over a while back, and noticed what I think you
want to do implemented within the config.vms file there.
I would guess that whomever implemented that within config.vms
simply set up the shortened symbol values based on empirical
compilation -- you can use the CXXDEMANGLE command and the
CC/REPOSITORY support here, too.
Based on the HP C++ documentation, there do look to be some
differences here between OpenVMS Alpha and OpenVMS I64, too.
For interface details, the C++ manuals point to this site:
http://www.codesourcery.com/cxx-abi/abi.html
[FWIW, the usual CRC seen on OpenVMS is available via lib$crc(),
and most stuff I'm aware of seems to be using the AUTODIN II
CRC -- I do not know what CRC was used by the C team, however.
(The code I implemented for recent OpenVMS releases generates
the AUTODIN II, however -- this CRC is common across Ethernet,
EFI, DECnet and at least a few other spots, and it's buried
in parts of OpenVMS, too, FWIW.) I'd *NOT* go after the CRC
directly, but would use the materials from the documentation
around external symbols.]
There's a reference to mangling in the shareable image cookbook:
http://h71000.www7.hp.com/wizard/swdev/ovms-shexe-cook.html
specifically to the C++ mangling materials in:
SYS$COMMON:[SYSHLP.EXAMPLES.CXX]
The SW.CXX examples and friends were omitted from C++ V6.5,
but versions of around V5.6 and up should have an example.
The examples are apparently being reworked -- I don't know
about the release schedule, if any, however. (The support
folks will likely be able to get you an official update on
the status and plans, or potentially an early copy of these
if such is available -- I'd certainly ask.)
--
I'm playing "loose" with the term "mangling" here, as C++
has rather more around this than just shortening the symbol.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com