Typecasring SHORTCARD/CARDINAL/LONGCARD 
Author Message
 Typecasring SHORTCARD/CARDINAL/LONGCARD

I have a question related to something I use quite often:

Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
affect programs in a significant way?

For instance:
  x : CARDINAL;
  y : LONGCARD;

  y := LONGCARD(x);

Is it ok to use this sort of thing frequently? My application would waste to
much memory if I made all of type LONGCARD, for instance. But what other
things should I be on the lookout for? And why is the difference between the
above example and:

  y := SYSTEM.VAL (LONGCARD,x);

Cheers
Charl Gerber                            
--
My personal web page : http://www.*-*-*.com/
South African Soccer Web Page : http://www.*-*-*.com/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
            "I follow where my mind goes" - Psychedelic Furs
     "Please, please, please, let me get what I want" - The Smiths
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:
> Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
> affect programs in a significant way?

> For instance:
>   x : CARDINAL;
>   y : LONGCARD;

>   y := LONGCARD(x);

> Is it ok to use this sort of thing frequently? My application would waste to
> much memory if I made all of type LONGCARD, for instance. But what other
> things should I be on the lookout for? And why is the difference between the
> above example and:

>   y := SYSTEM.VAL (LONGCARD,x);

According to PIM3:

* Type transfer functions change type but not representation.
  Usually, the only restriction is that both types must occupy the
  same size.

* VAL (is a standard function and needs not to be imported from SYSTEM)
  not only changes the type but is also free to change the representation.
  Both types must belong either to the CARDINAL/INTEGER/CHAR family,
  or be enumerations types, or subranges thereof.

Considering this, ``y := LONGCARD(x)'' will not work if LONGCARD
is indeed longer than CARDINAL but ``y := VAL(LONGCARD, x)'' should work.

You should, if ever possible, do your conversions by VAL, ORD, CHR,
FLOAT, TRUNC, and assignments. Type transfer functions are not
guaranteed to work in a portable way and should therefore be avoided
or isolated.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:
> I'm not entirely sure, but the last time this question was asked, somebody
> said that some compilers don't clear the more significant part in a normal
> typecast(y:=LONGCARD()), and that the VAL way is always safe (language
> definition). I'm not sure about this, and I don't know if such akward
> compilers still exist.

Compilers which support

   y := LONGCARD(x); (* x: CARDINAL; y: LONGCARD; *)

are awkward if LONGCARD is actually larger than CARDINAL. Wirth
states that ``they involve no explicit conversion instructions''.
Therefore the effect is fairly undefined if your compiler happen
to support it.

VAL on the other hand, adapts the representation on conversions
(by filling the more significant part with zeroes, for example) and
is free to include runtime checks which are useful in cases like

   VAL(CARDINAL, y); (* y: LONGCARD *)

where y could be too large to fit into CARDINAL.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Quote:

>Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
>affect programs in a significant way?
>For instance:
>  x : CARDINAL;
>  y : LONGCARD;
>  y := LONGCARD(x);
>Is it ok to use this sort of thing frequently? My application would waste to
>much memory if I made all of type LONGCARD, for instance. But what other
>things should I be on the lookout for? And why is the difference between the
>above example and:

I do it all the time, but I limit it by choosing the types smartly.

It's no problem under TopSpeed. You could run into problems with other
compilers which not clear the more significant part.

Quote:
>  y := SYSTEM.VAL (LONGCARD,x);

Exactly the same I believe. When I'm home, I'll try to check the difference
by dissassembly.

I'm not entirely sure, but the last time this question was asked, somebody
said that some compilers don't clear the more significant part in a normal
typecast(y:=LONGCARD()), and that the VAL way is always safe (language
definition). I'm not sure about this, and I don't know if such akward
compilers still exist.



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Quote:

> Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
> affect programs in a significant way?

> For instance:
>   x : CARDINAL;
>   y : LONGCARD;

>   y := LONGCARD(x);

> Is it ok to use this sort of thing frequently? My application would waste to
> much memory if I made all of type LONGCARD, for instance. But what other
> things should I be on the lookout for? And why is the difference between the
> above example and:

>   y := SYSTEM.VAL (LONGCARD,x);

I assume you are using TopSpeed Modula-2, because this:
y := LONGCARD(x);
is a TopSpeed extension, which in some cases is interpreted as a type conversion
and in some cases as a type cast, if I remember correctly. I recommend you use
y := VAL (LONGCARD,x);  (* SYSTEM isn't required *)
instead, because that is a type conversion. The difference between conversion
and casting is that conversion 'knows' about the types while casting just
interprets the same data as a different type. Thus casting depends on the
data representation used by a particular compiler and is not portable.

Egbert



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Typecasting in TopSpeed is not always type casting.
For casting from one ordinal type to another ordinal type, the TopSpeed
compiler does a type conversion, NOT a type cast. This is not PIM standard
M2.
If you typecast a ordinal type to a record or array then a type cast is
done.

Thus in the TS M2 implementation
   CARDINAL(LONGCARD) = VAL(CARDINAL, LONGCARD);
and other obvious permutations

--
Norman Black
Stony Brook Software
To reply via email remove the ".dud" from my address.



Quote:
> I have a question related to something I use quite often:

> Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
> affect programs in a significant way?

> For instance:
>   x : CARDINAL;
>   y : LONGCARD;

>   y := LONGCARD(x);

> Is it ok to use this sort of thing frequently? My application would waste
to
> much memory if I made all of type LONGCARD, for instance. But what other
> things should I be on the lookout for? And why is the difference between
the
> above example and:

>   y := SYSTEM.VAL (LONGCARD,x);

> Cheers
> Charl Gerber                            
> --
> My personal web page : http://www.geocities.com/Colosseum/6149/index.html
> South African Soccer Web Page : http://picturenet.co.za/sasoccer/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>             "I follow where my mind goes" - Psychedelic Furs
>      "Please, please, please, let me get what I want" - The Smiths
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Tue, 25 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Quote:

> I have a question related to something I use quite often:

> Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
> affect programs in a significant way?

> For instance:
>   x : CARDINAL;
>   y : LONGCARD;

>   y := LONGCARD(x);

> Is it ok to use this sort of thing frequently? My application would waste to
> much memory if I made all of type LONGCARD, for instance. But what other
> things should I be on the lookout for? And why is the difference between the
> above example and:

 This form of TYPECAST needs care for portability, and should be used
when MEMORY is
tight ( eg in our Mod51 80x51 embedded  compilers, it is very tight,
relative to a 32MB PC !)

 Beware CARDINAL(RealVar) and REAL(Cardinal), which are mostly handled
as Conversions
more than the memory-remap cast.

 Also, watch for a DECREASE in efficency on 32 bit native compilers,
using BYTE sized elements
( look as the DISASM output, and often you will see AND's to clear the
hi byte(s) ).

 To test for this, use a alias type, and try various sizes.

 On a Windoze PC, Memory is not usually a problem, but for DBASE files,
PCMCIA cards etc,
it can help to 'pack' your data types more carefully.

 So, your style will vary slightly depending on the target.

- jim

Quote:

>   y := SYSTEM.VAL (LONGCARD,x);

> Cheers
> Charl Gerber
> --
> My personal web page : http://www.geocities.com/Colosseum/6149/index.html
> South African Soccer Web Page : http://picturenet.co.za/sasoccer/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>             "I follow where my mind goes" - Psychedelic Furs
>      "Please, please, please, let me get what I want" - The Smiths
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

--
======= Manufacturers of Serious Design Tools for uC and PLD  =========
= Optimising Modula-2 Structured Text compilers for ALL 80X51 variants
= Reusable object modules, for i2c, SPI and SPL bus interfaces
= Safe, Readable & Fast code - Step up from Assembler and C
= Emulators / Programmers for ATMEL 89C1051, 2051, 89C51 89S8252 89C55
= *NEW* Bondout ICE for 89C51/89C52/89C55



Thu, 27 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:
> I have a question related to something I use quite often:

> Typecasting between CARDINAL / SHORTCARD / LONGCARD values - does it
> affect programs in a significant way?

> For instance:
>   x : CARDINAL;
>   y : LONGCARD;

>   y := LONGCARD(x);

> Is it ok to use this sort of thing frequently? My application would waste to
> much memory if I made all of type LONGCARD, for instance. But what other
> things should I be on the lookout for? And why is the difference between the
> above example and:

>   y := SYSTEM.VAL (LONGCARD,x);

It's right way: typecasting between CARDINAL / SHORTCARD / LONGCARD values
using such expression:

  TYPE1_VAR := TYPE1 (TYPE2_VAR)

Function VAL is more useful for user defined types, for example:

TYPE
  Color    = ( Black,     Blue,         Green,      Cyan,
               Red,       Magenta,      Brown,      LightGray,
               DarkGray,  LightBlue,    LightGreen, LightCyan,
               LightRed,  LightMagenta, Yellow,     White );
VAR
  y : LONGCARD;
BEGIN
  y := VAL (LONGCARD, ORD(Green));

I think there is no difference for compiler between  y:= LONGCARD(x) and
y:= SYSTEM.VAL(LONGCARD, x). :)
Look at this disassembled code (JPI TopSpeed 3.02, debug => full):

Line 7    y := LONGCARD(x);
3A7C:0009 mov   bx,0
3A7C:000C mov   ax,[008A]
3A7C:000F mov   [008C],ax
3A7C:0012 mov   [008E],bx
Line 8    y := VAL (LONGCARD,x);
3A7C:0016 mov   bx,0
3A7C:0019 mov   ax,[008A]
3A7C:001C mov   [008C],ax
3A7C:001F mov   [008E],bx

Bye...
Alexander Volkanov



Fri, 28 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Quote:


[...]
> >   y := LONGCARD(x);
[...]

>  This form of TYPECAST needs care for portability, and should be used
> when MEMORY is
> tight ( eg in our Mod51 80x51 embedded  compilers, it is very tight,
> relative to a 32MB PC !)

It is a fundamental misunderstanding if type functions are considered
to be like type casts of C. Type functions do not generate code.

Quote:
>  Beware CARDINAL(RealVar) and REAL(Cardinal), which are mostly handled
> as Conversions
> more than the memory-remap cast.

CARDINAL(realvar) and REAL(cardinalvar) should be rejected by the compiler.

Quote:
>  Also, watch for a DECREASE in efficency on 32 bit native compilers,
> using BYTE sized elements
> ( look as the DISASM output, and often you will see AND's to clear the
> hi byte(s) ).

This depends on the architecture. RISC architectures usually do not
have this problem.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Fri, 28 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD



Quote:
> Typecasting in TopSpeed is not always type casting.
> For casting from one ordinal type to another ordinal type, the TopSpeed
> compiler does a type conversion, NOT a type cast. This is not PIM standard
> M2.
> If you typecast a ordinal type to a record or array then a type cast is
> done.

> Thus in the TS M2 implementation
>    CARDINAL(LONGCARD) = VAL(CARDINAL, LONGCARD);
> and other obvious permutations

I consider the TS shorthand for type conversion to be much neater,
despite it being seriously out of line with the standard.

It does however make for interesting portability problems since
standard implementations are entitled to do a pure typecast.
Mechanical conversion to ISO/PIM is possible though the resulting
expressions become horribly clumsy.

Regards,
--

Scientific Software Consultancy             /^,,)__/



Fri, 28 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:


> > Thus in the TS M2 implementation
> >    CARDINAL(LONGCARD) = VAL(CARDINAL, LONGCARD);
> > and other obvious permutations

> I consider the TS shorthand for type conversion to be much neater,
> despite it being seriously out of line with the standard.

Unfortunately Wirth had already defined

  CARDINAL(x) = CAST(CARDINAL, x)

otherwise the ISO standard would probably have allowed the TS shorthand.
As it was, there were too many conflicting interpretations of CARDINAL(x)
so it was removed completely.

Martin



Sat, 29 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD



Quote:

>  Tom Brown) writes:


> > > Thus in the TS M2 implementation
> > >    CARDINAL(LONGCARD) = VAL(CARDINAL, LONGCARD);
> > > and other obvious permutations

> > I consider the TS shorthand for type conversion to be much neater,
> > despite it being seriously out of line with the standard.

> Unfortunately Wirth had already defined

>   CARDINAL(x) = CAST(CARDINAL, x)

> otherwise the ISO standard would probably have allowed the TS shorthand.

That which is defined can always be redefined. I bet there are
very few programs about which rely heavily on the PIM definition.
For the most part only bit twidders ever want to CAST types.

Quote:
> As it was, there were too many conflicting interpretations of CARDINAL(x)
> so it was removed completely.

A monumental triumph of precise verbosity over readability.

Regards,
--

Scientific Software Consultancy             /^,,)__/



Sun, 30 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD

Quote:

> I think there is no difference for compiler between  y:= LONGCARD(x) and
> y:= SYSTEM.VAL(LONGCARD, x). :)
> Look at this disassembled code (JPI TopSpeed 3.02, debug => full):

This is true in TopSpeed. But if you read the manual you will
find that this is explicitly stated to be a language extension.

A compiler that complies with Wirth's books, PIM, will not
properly convert types with y:= LONGCARD(x). I haven't
checked, but one poster said that the compiler would reject
this (or is that when the container type is too small), or
it could just copy the bitmaps, or as much as will fit. Anyway,
neither is the required behaviour so the TopSpeed code will not
be portable if you use y:= LONGCARD(x).

--

Terry Moore, Statistics Department, Massey University, New Zealand.

Theorems! I need theorems. Give me the theorems and I shall find the
proofs easily enough. Bernard Riemann



Sun, 30 Jan 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:

> > Unfortunately Wirth had already defined

> >   CARDINAL(x) = CAST(CARDINAL, x)

> Wirth has never defined a CAST function.

That's right, he defined CARDINAL(x) to give the functionality that
CAST(CARDINAL, x) gives in ISO Modula-2. Sorry if my shorthand way
of expressing this caused confusion.

Martin



Tue, 01 Feb 2000 03:00:00 GMT  
 Typecasring SHORTCARD/CARDINAL/LONGCARD


Quote:
> That is most definitely a matter of opinion. As you are no doubt aware,
> interpreting a datum of one type as another type is described as casting
> it. I find it quite *logical* to call the function CAST -- and I cannot
> see that this in any way affects the *readability* of the expression.
> (It does, of course, make it a bit longer to *write*.)

I agree with you -- replacing type functions by CAST means that
you are able to find easily all locations where type conversions
are applied.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Tue, 01 Feb 2000 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Convert Date/time from LONGCARD to String ?????

2. help on longcard

3. LONGCARD compiler support ?

4. LONGCARD,CARD and graphics.

5. (in)compatibility between INTEGER and CARDINAL

6. (Copy) (in)compatibility between INTEGER and CARDINAL

7. CARDINAL and INTEGER number in Mod-2

8. from ORD to CARDINAL to CONVERT

9. Cardinal numbers

10. Cardinal numbers or unsigned int..

11. INC(CARDINAL,INTEGER) problem

12. Getting a CARDINAL into a zero-padded ARRAY OF CHAR

 

 
Powered by phpBB® Forum Software