NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/634

Text File | 1996-08-05 | 8.6 KB | 244 lines

Path: nntp.teleport.com!sschaem
From: [e-mail] (Stephan Schaem)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: 9 Jan 1996 22:18:47 GMT
Organization: Teleport - Portland's Public Access [phone]
Message-ID: <4cupk7$[e-mail]>
References: <[e-mail]> <[e-mail]> <4c9i2l$[e-mail]> <4ck47h$[e-mail]> <[e-mail]> <4cokkg$[e-mail]> <[e-mail]> <4cqrti$[e-mail]> <[e-mail]>
NNTP-Posting-Host: kelly.teleport.com
X-Newsreader: TIN [version 1.2 PL2]

Jason S Birch ([e-mail]) wrote:
: [e-mail] (Stephan Schaem) writes:

: > polymorphism?

: > int a,b,c;

: > ...
: > a = b /c;
:         ^
: > a *= result;
:     ^
: The "/" and "*" are polymorphic - you can use them in any mathematical
: expression, without caring whether the left and right sides are chars,
: shorts, longs, floats, doubles, or any equivalent type. If they were
: not polymorphic, you might have, for example:
: a int= b int/ c;
: a int*= result;

 I wanted to show that if you dont know your variable type range you
 might write code that wont compile (here, the user go back and cast.. or
 realize he was using the wrong type for his kind of operation, or is waistfull)

: This is essentially what you have in assembler. Note that with C++,
: you can overload "+", "-", "*", "/", "=", etc, to work with any custom
: classes as well, so you could have, for example:

 At that level in asm, you will probably use an 'object' structure that
 include those function.

: vector a,b,c;
: real r;
: ...
: a = b + c;
: r = a * b;
: cout << "Values are: " << a << ", " << r << ".\n";

    movea.l    (GLOBAL_VECTOR,a4),a6    ;the type we are working on

;with macro
    SET    GLOBAL_a_VECTOR, GLOGAL_b_VECTOR, GLOGAL_c_VECTOR
    CALL    VECTOR_Add

;without (variable type extenstion omited)
    lea    (GLOBAL_result,a4),a0
    lea    (GLOBAL_a,a4),a1
    lea    (GLOBAL_b,a4),a2
    jsr    (VECTOR_Mul,a6)
;or
    pea    (GLOBAL_r_REAL,a4)
    pea    (GLOBAL_result_VECTOR,a4)
    jsr    (VECTOR_ToReal,a6)

 I will skyp the output.

 Not very elegant I must say... but I would code something like this
 if you asked me: I have 3 VECTOR, a, b, c , I want a to be equal to b + c
 and the real r to hold the result of a * b.

 C++ is way more elegant and usable at this level. But I would still know
 r is a real, and that I'm working with vector.

: and have, say:

: Values are: [3,7,3], 67.

: as the output.

: > struct.float = a;

: This is polymorphism of "=", but it's also taking advantage of the
: fact that C can convert an integer into a float.

 It doesn't hurt to tell explicitly the compiler that you actually
 want to convert an int into a float by using the cast operator. I
 assume you know at the time of writting that you are converting
 an int into a float since this step is a logical part of the program.

: > I dunno , I just find it puzzling to declar variable without giving
: > a care of what its usage will be. You programing practice is VERY unwise...

: Your misunderstanding is that you think he means he has no idea of
: what types each variable is, whereas what he's saying is he need have
: no idea of how each type is actually implemented on a particular
: machine/OS - all he has to do is know how those types are defined to
: behave under ANSI C. In fact, if you want to write portable code, you
: have to restrict your knowledge of behaviour of the types to that
: which is guaranteed under ANSI C. Taking advantage of any other
: information you might have (eg. endian-ness, number of bits) limits
: your portability.

 My understanding was has follow... After I declare my variable I can
 forget their type (The type here beying a 16bit word). Ok, he can
 forget its a 16bit word... but he cant forget that its a CHIPREG type
 and that the CHIPREG type is 16bit, unless he never mix type operation.

: >: I know better than to declare a value as unsigned long when I'm
: >: going to assign a clock_t to it.  And if I did, I'd lose the
: >: fractional part of a floating-point clock_t, not the upper 32 bits.

: > You said yourself after peeking at the .h that clock_t was a ulong.
: > But you know better then not using a ulong... ? Should I assume
: > you alway use the largest data type available,double ? (What a waist)

: No, you should use clock_t! If you want a variable to use in functions
: that expect a clock_t, you declare it thus:

 I had the idea clock_T was a structure member of type ulong.

: clock_t Stephens_var;

: You do *not* declare it as:

: ulong Stephens_var;

: even if you *know* that on your particular implementation, that's what
: it really is, because that restricts your portability.

 I agree... you shouldn't even know clock_t is a ulong, just its
 type description.


: > And you mean you would loose the fractional part of clock_t if you
: > used ulong , not the upper 32bits? This make absolutly no sense since
: > we are talking about interger types.(BTW copy 0x00000001 into a 2byte int,
: > you will loose the upper 16bit... )

: You lose nothing if you declare it as clock_t.

 I didn't see clokc_t has a type, but a structure member of type ulong.

: > If the header file was programmed correctly it would not use ANSI data
: > type directly....

: Why not? You should just know better than to look at it and take
: advantage of that information.

: Incidentally, when I create a custom data type I want to keep private,
: I provide a public header file similar to:

: typedef void *MyDataType;

: MyDataType *MDT_Create(...);
: void MDT_Dispose(MyDataType *);

 If you look at my C projects you will find

 *_PRV.h (function group name), *_PUB.h  , *_*.h (here the second * is the
 platform name)

 The PRV usually hold library private, PUB what the user is
 allowed to know (mainly the function tags, flags, etc and prototyping),
 the platform header define the private structure of the private header (PRG.h)

 but what I wanted to say is _PUB function prototyping is simple:

pvoid    GroupName_Function(TAGS);

 true for all...

: and inside the private header file, I actually define what MyDataType
: is. This way, no-one can "accidentally" use the internal definition,
: and I am free to change it at will, without having to worry about
: those who *don't* know better than to look at it and take advantage of
: the information.

 for me pvoid is a pointer to a struture with this alway true

 structure    STRUCTURE {
    link lnk;
    ...

 lnk hold an ID element...

 The ID hold the type of the structure... it can be of type
 ID_ERROR, or whatever... probably a structure that hold
 private, public and os element.

: > The way you get optimal speed is optimizing the optimal algorithim.
: > If you stop at the algorithm you loose... Optimizing at this stage
: > will give an exponential result on the work you done on the algorithm.
: > And usually this stage is done in assembler.

: The problem is, do you want portable code? If yes, then you should be

 Yes, I want portable code.. and other time I want the fastest code
 the machine can provide (To the point where it suffient and doesn't
 overcome the effort).

: aware that what might be optimal for one particular CPU using one
: particular compiler is not necessarily the same for another. For

 Very true... ex: I do not use self incrementing pointer on a mips box.

: example, scanning through an array and adding the contents using array
: dereferencing and a moving pointer: On an 040 Amiga, the latter was
: faster; using gcc on a Sun, both produced the same assembler code; and
: using Metrowerks on a PowerMac, the former was actually quicker
: because the pointer method used post-incrementing (ie. sum += *ptr++)

 Now, what I would probably write on <= R4K box or CPU that has free
 immediate index addresing mode:

 sum += ptr[0];
 sum += ptr[1];
 sum += ptr[2];
 sum += ptr[3];
 sum += 4;

 On a 680x0 amiga:

 sum += *ptr++;
 sum += *ptr++;
 sum += *ptr++;
 sum += *ptr++;

: and the compiler wasn't smart enough to realize it didn't need to
: store the pre-incremented value and used an extra register to store
: it. The moral? Don't make assumptions about what is an optimization,
: and what isn't, unless you test it on every combination you plan to
: run it on.

 I do not assum... But if I do and care about portability of the
 non OS specific code I would make sure to include SYSTEM flag.
 and compile the right version of the code I tryed to optimize at the C
 level.

 For obvious resaon I fall back to asm for the optimum optimized part,
 usually a mirror or the 'optmized' C code.

 Stephan