No subject

suggesting, it sounds to me that you're still trying to program in a
procedural language, rather than getting into the Java mindset.

> (1) Data types: in assembler, any data can be used in any operation
> regardless of type. In COBOL, all data is typed, but an area of memory
> can be "redefined" as two or more different types (similar to C's union).
> In Java, all data has a single type and cannot be recast or unioned.
> The workaround for this is to determine the "main" type for each data item,
> and declare it as that type, then develop conversion functions
> for when the program wants to apply a different operation on a type
> (eg convert a number to a string of bytes, or vice-versa).

A more OO solution to this would be to create different classes for
each of the possible types, and then either define polymorphic
functions that accept arguments of each type, or make the classes
implement the same interface so that they have the same methods and
accessor functions.

There will be an increased overhead from using classes instead of
primitive types but, unless you're in a highly performance critical
section of code, it usually doesn't make a great deal of difference.

> (2) Pointers: specifically pointer arithmetic. Java only has a limited
> form of pointers (references) with no pointer arithmetic or way to get
> the address of a data item, or convert a number to an address.
> The workaround here would be to pass a reference to the data to
> a C function which returns an integer. The integer being simply
> the address that the function was passed. Dereferencing a pointer
> stored in an integer would word in the same way: pass an integer
> to a C function which returns a pointer to the data (with the pointer
> being simply the integer which was passed).
> One problem here is that Java may not lay out data in memory
> in an exact sequence: for assembler to C conversion we had
> to put all the data into one large struct which was defined as packed.
> This ensured that an offset from the address of one data item
> would pick up the right data. In Java this may be more difficult.
> Another problem is garbage collection: the Java garbage collector
> might move data around and invalidate all the "fake pointers".
> We might have to define any data we want to take the address of
> on the "C side" of the boundary.

Java certainly doesn't do pointer arithmetic and what you're
suggesting sounds very scary and error prone.

There are a couple of ways of accessing memory, such as the
ByteBuffer, but I know almost nothing about these.  Why are you
needing to do this type of memory manipulation?  Is there any way you
could avoid getting so close to the bare metal?

- olly