#: 17260 S3/Languages
    17-Dec-92  08:36:10
Sb: #17255-#C question
Fm: Pete Lyall 76703,4230
To: Bill Dickhaus 70325,523 (X)
Bill...
Interesting question.... what about:
  a) Take address of structure
  b) Take address of interesting element
  c) Subtract a) from b)
  d) Assign result to a variable
Pete
There is 1 Reply.

#: 17262 S3/Languages
    18-Dec-92  08:50:54
Sb: #17260-#C question
Fm: Bill Dickhaus 70325,523
To: Pete Lyall 76703,4230 (X)
Pete,
I hadn't thought of that one, but like Bob's suggestion, it is a runtime
method, which I wanted to avoid. The simplest runtime solution, in this
particular case, is to assign the address of each element to an array of
pointers. I was hoping there was some way to initialize variables to the
offsets at compile time. I could do it with #asm, I think, but really didn't
want to. I think I'll just leave it like it is, which is all runtime type
stuff. The purpose of this was to reduce the size of the code, since I'm having
great fun trying to pack a lot of program into 48K, or 40K in some cases, for
the CoCo. What is one OSK module is now four OS9 modules, and I think I'm going
to have to go to five.
        -Bill-
There is 1 Reply.

#: 17265 S3/Languages
    18-Dec-92  20:47:46
Sb: #17262-#C question
Fm: Bob van der Poel 76510,2203
To: Bill Dickhaus 70325,523 (X)
Bill, I don't want to get into any arguments here...but both my and Pete's
suggestions were compile time. Uh, maybe you should upload a snippet of code so
we can be sure we're all talking about the same thing...
BTW, is this for your auto-cis program? How's it coming?
There is 1 Reply.

#: 17268 S3/Languages
    19-Dec-92  10:58:38
Sb: #17265-C question
Fm: Bill Dickhaus 70325,523
To: Bob van der Poel 76510,2203 (X)
Bob,
Yes its for the auto-CIS (auto-Delphi, too) program, which is called InfoXpress
(IX for short). IX is coming along, but slowly. I had thought I would have more
free time to work on it, which just hasn't happened. I was hoping to have a
shareware version available for the CoCo by now. The biggest stumbling block
with the CoCo is the 64K per process limitation, but so far I've managed.
I went back and looked at your suggestion, and you're right, it is compile
time. But when I apply your suggestion to my problem, I end up with run time
code because I'm dealing with pointers to structures that are passed from other
functions. I could copy the passed structure to a local structure and use your
suggestion (I hadn't thought of that until just now).
Pete's suggestion can actually be interpreted as either compile time or run
time, and again, in this particular situation it would be run time.
After asking the question, and further thought on a solution, I think I've
decided to leave it as it is, it will be easier to maintain, and since the
functions involved save and load the configuration file for IX, I expect the
code is going to change frequently.
        -Bill-

#: 17280 S3/Languages
    23-Dec-92  14:43:14
Sb: #17255-#C question
Fm: Carl Kreider 71076,76
To: Bill Dickhaus 70325,523 (X)
Bill,
Here is the classical method of finding a struct element offset, if this
is what you meant.
#define offsetof(t, m)  (&(((t *)0)->m))
typedef struct {
    char    a;
    int     b;
    short   c;
    } X;
main()
    {
    printf("offsetof(b) = %d\n", offsetof(X, b));
    }
There is 1 Reply.

#: 17285 S3/Languages
    24-Dec-92  08:23:32
Sb: #17280-#C question
Fm: Bill Dickhaus 70325,523
To: Carl Kreider 71076,76 (X)
Carl,
That's not exactly what I was looking for (I was looking for something that I
could use to initialize an offset table at compile time) but its something I
have filed away for future reference. Thanks.
        -Bill-
There is 1 Reply.

#: 17299 S3/Languages
    28-Dec-92  20:58:24
Sb: #17285-C question
Fm: Carl Kreider 71076,76
To: Bill Dickhaus 70325,523 (X)
Ok.  I wasn 't clear whether you wanted the offset of a member within a struct
(ie with respect to the start of the struct) or the location in memory of a
member of a struct.

#: 17318 S3/Languages
    02-Jan-93  20:45:46
Sb: RMA's "common" command
Fm: David Breeding 72330,2051
To: all
  Can anyone shed any light on the "common" assembler directive that is
embedded in the "RMA".  In the process of disassembling it, I came across this
command in the list of commands, but it is not documented in the documentation
(for the CoCo).  An rdump of an rof with the -a option allows for common
blocks, but as I mentioned, there is no mention of it in the docs.  If you
enter the line [space]common[space]3, for example, an rdump of the rof gives "1
common block, label, size 3, 0 references:. Oh, yes, common must have a label
before it, too.
  I just wodered if we might be able to use it somehow.

#: 17435 S3/Languages
    25-Jan-93  19:26:56
Sb: Patch for RMA
Fm: David Breeding 72330,2051
To: All
  I've just uploaded a file to patch the "rma" supplied with the CoCo Level 2
Development Pak.  It adds support for the 6309 CPU.  The file is in Lib 3
(Languages), the name is "rmapat.ar".  You will need "ar" and "ipatch" along
with the stock version of "rma".  I did not include a patch to c.asm for those
not having "rma".  One addition I did make to the program is the ability to
create edition 0 ROF's so that one could create public library files
(c.link-compatible).
  One note:  I have just now completed the project and there may possibly be
bugs.  Be watchful for a while.  There may be a few bugs in the old 6309 codes
also, as I had to change some of the data types to allow for the 32-bit stuff. 
I'd appreciate anyone who is interested to download it and test it out.
    David...

#: 17467 S3/Languages
    02-Feb-93  16:19:23
Sb: #C question
Fm: Bill Dickhaus 70325,523
To: all
Any idea how I can get the following to compile on the CoCo? It compiles and
executes just fine on my MM/1. I'm guessing that the definition of func in
function test() is not correct, but I've tried all the variations I can think
of.
 /* test4.c
  */
 static test2();
 main(argc,argv)
 int  argc;
 char *argv[];
 {
     test(0, test2);
 }
 test(type, func)
 int type;
 int (*func)();
 {
     (func)();
 }
 test2()
 {
     puts("test2()\n");
 }
Compiling this source code on the CoCo results in this:
 test4.c : line 16  ****  not a function  ****
  (func)();
   ^
        -Bill-
There is 1 Reply.

#: 17469 S3/Languages
    03-Feb-93  09:36:46
Sb: #17467-#C question
Fm: Pete Lyall 76703,4230
To: Bill Dickhaus 70325,523 (X)
Bill -
It's been a while since I messed with function pointers (I always have to look
them up!), but I'm thinking you'd invoke the function by dereferencing it..
    *woof(args);
Well..
Just peeking at C++ The Complete Reference (ISBN 0-07-881654-8), page 128
indicates that you call the function normally..
    func();
Give it a shot, and let me know... this has always been a weak area for me.
Pete
There is 1 Reply.

#: 17470 S3/Languages
    03-Feb-93  17:01:56
Sb: #17469-#C question
Fm: Bill Dickhaus 70325,523
To: Pete Lyall 76703,4230 (X)
Pete,
I just tried that, and that didn't work either. I still think that the problem
is in the definition of the passed pointer. I'm beginning to suspect that the
6809 compiler just doesn't know how to handle this particular situation.
I'm going to post the same question elsewhere, maybe James Jones can shed some
light.
        -Bill-
There is 1 Reply.

#: 17480 S3/Languages
    06-Feb-93  00:17:09
Sb: #17470-#C question
Fm: Kim Kempf 71161,3221
To: Bill Dickhaus 70325,523 (X)
Try this:
   (*func)()
Since func is a pointer to a function you need to dereference it.  But the
parens are needed to dereference the function pointer rather than the returned
value of the function.  Hope this helps.
kim
There is 1 Reply.

#: 17482 S3/Languages
    06-Feb-93  08:44:17
Sb: #17480-C question
Fm: Bill Dickhaus 70325,523
To: Kim Kempf 71161,3221 (X)
Kim,
Thanks! I knew I was close, but wasn't sure what I was doing wrong. I've used
pointers to functions before, but not ofte{n enough to remember exactly how it
all works.
        -Bill-

#: 17473 S3/Languages
    03-Feb-93  21:56:02
Sb: #struct pointer trouble
Fm: GLEN HATHAWAY 71446,166
To: all
 Hi all... I'm playing with a C function to do graphic fills. I'm using an
algorithm (and code) from Graphics Gems (edited by Andrew S. Glassner. I'm
getting lots of errors from the linker like this:
     *** error - value out of range ***
     00042   move.l 80028(sp),d1
 Here are the pertinent parts of the code:
     typedef struct{short y, xl, xr, dy;} segment
     #define MAX 10000
     #define PUSH(Y, XL, XR, DY) \
         if(sp<stack+MAX && Y+(DY)>=0 && Y+(DY)<=maxx) \
         {sp->y=Y; sp->xl=XL; sp->xr=XR; sp->dy=DY; sp++;}
     #define POP(Y,XL,XR,DY) \
         {sp--; Y=sp->y+(DY=sp->dy); XL=sp->xl; XR=sp->xr;}
     fill(x,y,nv)
     int x,y,nv;
     {
         segment stack[MAX], *sp=stack;
         PUSH(y,x,x,1);
         PUSH(y+1,x,x,-1);
         .
         .
         .
         POP(y,x1,x2,1);
         etc.....
     }
 Looks to me like it defines an array of 10000 copies of struct segment, then
defines a pointer (sp) of type 'segment' to the structures to allow variables
to be stacked and unstacked 4 at a time.
 Anybody know how to make this work on my MM/1. I'm not enough of a C guru to
solve it (so far).
 Thanks in advance. Glen Hathaway - COMPER - 71446,166
There is 1 Reply.

#: 17476 S3/Languages
    04-Feb-93  11:09:01
Sb: #17473-#struct pointer trouble
Fm: Pete Lyall 76703,4230
To: GLEN HATHAWAY 71446,166 (X)
Glen -
If you're using a compiler that's generating 68000 code, your offsets are
limited to +/- 32K.. anything beyond that requires that you use a 'remote'
storage class.
If you're generating code for an 020 or greater, all offsets are 32 bits, and
no special attention is required.
Pete
There is 1 Reply.

#: 17478 S3/Languages
    04-Feb-93  22:09:48
Sb: #17476-#struct pointer trouble
Fm: GLEN HATHAWAY 71446,166
To: Pete Lyall 76703,4230 (X)
Hi Pete... You're exactly right! James Jones pointed that out to me last night.
I downsized the thing and it works great. Probably on really super- complex
fills it might run out of space, but I haven't killed it yet. Now to refine it
and convert to assembler... Thanks for the help.
 Glen Hathaway - COMPER - 71446,166
There is 1 Reply.

#: 17479 S3/Languages
    05-Feb-93  10:29:35
Sb: #17478-struct pointer trouble
Fm: Pete Lyall 76703,4230
To: GLEN HATHAWAY 71446,166 (X)
Good Glen -
I'm glad it all came out well.
Pete

#: 17558 S3/Languages
    21-Feb-93  10:17:21
Sb: #17478-#struct pointer trouble
Fm: Kevin Pease 70516,1633
To: GLEN HATHAWAY 71446,166 (X)
You could ask the c compiler to generate the assembler code and then just
optimize
that code. Much easier than manually convertinng to ASM
There is 1 Reply.

#: 17561 S3/Languages
    21-Feb-93  15:37:07
Sb: #17558-struct pointer trouble
Fm: GLEN HATHAWAY 71446,166
To: Kevin Pease 70516,1633
Hi Kevin... I find compiler generated assembler code very confusing. Everything
is stacked. I find I get lost quickly. I'm still playing with it tho...

#: 17626 S3/Languages
    05-Mar-93  20:15:41
Sb: #102 (bus) error
Fm: Ferranti Technologies 76264,1650
To: All
        We are working on a program that gives us a bus error evertime we
execute it from the command line, but it runs without error in srcdbg.  We are
using Ultra C and feel that there is something that we are not doing correctly
for using the csl module.  I far as I can see there is nothing required to make
use of the module but I don't know that for sure.  We also get a bus error
every time we run a program that requires the use of the fpu math library.
        Please Help!!
There are 2 Replies.

#: 17631 S3/Languages
    06-Mar-93  16:34:27
Sb: #17626-102 (bus) error
Fm: ole hansen 100016,3417
To: Ferranti Technologies 76264,1650
Hello Ferranti Technologies
In order to track dpwn the problem, I need to know what processor you are
using(68000,68020,68030,68040), as this might be processor dependent. For
instance the 68040 needs the fpu-library, as the builtin fpu does not do
anything the MC68881/68882 do, so you actually gets illegal opcodes ?? Do you
use 'ssm(system security module). This could also cause 'bus-errors' if
user-state tasks make access to memory, that is not allocated for it !! The
'csl'-module should be installed from 'init' during startup. It is a
traphandler that contains subroutines for the ultra-c-libraries much the same
way 'cio' does for the 'old' C.
regards ole@danelec.dk

#: 17634 S3/Languages
    06-Mar-93  19:29:53
Sb: #17626-102 (bus) error
Fm: Pete Lyall 76703,4230
To: Ferranti Technologies 76264,1650
Argh! I'm having the inverse problem - a program that runs fine standalone but
#102's under srcdbg. I wondered if size might be the issue, but James Jones
assures me that he's run stuff that's larger than mine without difficulties
(mine: exe = 122K, .DBG = 129K, and
STB = 15K).
Pete

#: 17651 S3/Languages
    07-Mar-93  19:38:37
Sb: #17631-#102 (bus) error
Fm: Ferranti Technologies 76264,1650
To: ole hansen 100016,3417 (X)
        We are using a 68040 in our system and I believe we have the ssm
installed.  I am going to try modifying the programs so that they will print a
message and exit.  Currently we have the programing printing a message and then
continuing on.  We never receive the message on the screen, I believe this is
because the program crashes before the system has a chance to print the
message.
There is 1 Reply.

#: 17687 S3/Languages
    10-Mar-93  15:39:00
Sb: #17651-#102 (bus) error
Fm: ole hansen 100016,3417
To: Ferranti Technologies 76264,1650 (X)
Hello Ferranti Tech.
if you have the 'ssm' in the bootfile/memory and it is installed in the
'init'-module, you will get 102-errors it you try to access memory out the
range, your task is granted during runtime. In attempt to troubleshoot your
problem, do the following:
out-comment the 'syscache' in the init-module(use 'moded') and before starting
the task, call 'rombug'(I do hope you use that to 'bootstrap' with) and enable
it(you must have autoboot disabled). then issue the following command to
'rombug': ovu2<cr> this will make rombug monitor any bus-errrors in
system/user-mode and if it catches any 'bus'-errors then you will get a 'big'
register-dump and a lot of information, but in order to make it informative,
you must disable 'syscache', because the 68040 has executed quite a number of
instructions in its internal cache, before the external 'timeout/bus-error'
occurs. You should be able to determine which instruction caused the problem.
It is likely to be some register-indirect addressing like :  move.b (a3),d0 and
the value of a3 gives you the address in error. It is also possible to let
'rombug' monitor all the vectors and watch the result(remember that os9 is
using some for 'syscalls'). If this does not give you a key, then you must
point some more out about what your program is doing: system/user-state, driver
written in 'C' - which gives you a problem with 'stack' in system-state(only 4k
granted from 'kernel') which mean you must assign local memory for your stack
!!
regards ole@danelec.dk
There is 1 Reply.

#: 17706 S3/Languages
    11-Mar-93  21:55:25
Sb: #17687-#102 (bus) error
Fm: Allan 70506,1173
To: ole hansen 100016,3417 (X)
  One note!!!  There is documented int the ultra C release notes -
  if you are using printf you MUST include stdio.h.  This is due to
  printf being ansi compliant now.  I ran into this problem myself
  Warning DO NOT comment out The SSM module  you system will take a
  VERY SEVERE performance hit ( about 5x).  The SSM module is required
  for user state programs to have cacheing.
  Allan R. Batteiger
  OS-9 Project Leader - MIZAR
There is 1 Reply.

#: 17710 S3/Languages
    12-Mar-93  01:31:13
Sb: #17706-102 (bus) error
Fm: ole hansen 100016,3417
To: Allan 70506,1173
hello Allan.
Did I say outcomment 'ssm', I ment 'syscache', as the information from 'rombug'
has shown to be hard to decode, with caching on. When you say performance
suffers 5 times, that wright for a running program, but when trying to catch
this buserror, it will help. It could also be a programming error that goes
away with caching disabled, and then you are half way finding the error.
regards ole

#: 17644 S3/Languages
    07-Mar-93  14:59:31
Sb: #17634-#102 (bus) error
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
If you ask Ole, he'll tell you that I'm the king of the 102 error. In most
cases my problem was in poor coding <grin>...what would run fine on one system
but would report 102s when run on a box with ssm. In 90% of the cases it was
the fault of passing a NULL pointer to a library string function. For example,
        char s1, s2;    /* global variables */
        if(strcmp(s1,s2)==0) foo();     /* foo() if strings the same */
would fail. This was a result of having s1 or s2 pointing to a dynamically
allocated string. In all cases I've had to change the code to something like
        if(s1 && s2 && strcmp(s1,s2)) foo();
Note that even this will cause a 102 if s1 is NULL:
        if(*s1 && s1) ...
However
        if(s1 && *s1) ...
will work.
Hmmm, you might try debug instead of srcdbg and see if that catches the error.
At least with debug you could determine the point of the error.
There is 1 Reply.

#: 17658 S3/Languages
    08-Mar-93  09:28:39
Sb: #17644-#102 (bus) error
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Bob -
I wish it WERE a program error... SrcDbg craps out before the program even gets
staged!
To make matters worse, the problem went away. I selective omitted new functions
and header files - no more #102. Added 'em all back in - still no #102. Arghh!
Pete
There is 1 Reply.

#: 17663 S3/Languages
    08-Mar-93  23:05:47
Sb: #17658-#102 (bus) error
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
I don't need to add that with ultra you need a different srcdbg?
There is 1 Reply.

#: 17676 S3/Languages
    09-Mar-93  09:33:42
Sb: #17663-#102 (bus) error
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Hmm - we haven't run our ULTRA yet, but neither copy has been installed or run
yet... A different SRCDBG? Any idea why?
Pete
There is 1 Reply.

#: 17679 S3/Languages
    09-Mar-93  20:01:33
Sb: #17676-102 (bus) error
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Could be that they needed a new srcdbg just for the fact that they don't have
cio and math anymore? I think the new one also fixes some bugs. I've not spent
much time with ultra or the new srcdbg myself.

#: 17798 S3/Languages
    25-Mar-93  14:59:05
Sb: #C++ compiler available
Fm: bye 70324,261
To: all
Does anyone know if there is a C++ compiler available for OS-9000 now?  We will
be starting a major software project shortly and I would like to start with a
C++ compiler.
Thanks in advance
-- Thad
There is 1 Reply.

#: 17803 S3/Languages
    26-Mar-93  09:46:31
Sb: #17798-#C++ compiler available
Fm: Pete Lyall 76703,4230
To: bye 70324,261 (X)
I believe the GNU compiler supports C++, but we're not using it at the moment.
Pete
There is 1 Reply.

#: 17822 S3/Languages
    29-Mar-93  08:48:20
Sb: #17803-#C++ compiler available
Fm: bye 70324,261
To: Pete Lyall 76703,4230 (X)
We are just looking into OS-9000, can you tell me what GNU stands for?  Who
markets it?
Thanks for the info!
-- Thad
There is 1 Reply.

#: 17823 S3/Languages
    29-Mar-93  09:15:52
Sb: #17822-#C++ compiler available
Fm: Pete Lyall 76703,4230
To: bye 70324,261 (X)
GNU is a sort of humorous, recursive acronym standing for:
   GNU is Not Unix
It is distributed by the free software foundation, and it is freeware.
Pete
There is 1 Reply.

#: 17826 S3/Languages
    29-Mar-93  16:50:52
Sb: #17823-C++ compiler available
Fm: bye 70324,261
To: Pete Lyall 76703,4230 (X)
Thanks, you have just enlightened one of the ignorant.
-Thad

#: 18591 S3/Languages
    24-Aug-93  16:54:15
Sb: #what the *?*{}
Fm: Carl Kreider 71076,76
To: gccoids
Are there any keepers of the gcc faith here?  I'm spoiling for a fight ;)
I just got version 2.4.5, and it sure seems badly broken to me.  I tried to
compile cawf with it to see how it did, and it throws up and causes the
assembler to throw up in any case but -m68000.  For other processors it
generates "tst.l" on address registers.  This is illegal. For example, this
fragment compiled with any optimization:
        char *np;                       /* name pointer */
        if ((np = getenv("CAWFLIB")) != NULL)
generates:
        bsr =getenv *b6
        move.l d0,a2 *m6c
        tst.l a2
An interesting side note is that the r68 that comes with ucc doesn't complain
about it......  Watch your butt if you use Ultra C.
Even more bizarre is this:
    gcc -m68020 -DSTDLIB -DSTDDEF -c pass2.c -o RELS/pass2.r
    pass2.c: In function `Pass2':
    pass2.c:1184: internal error--unrecognizable insn:
    (insn 5244 1870 1871 (set (reg:SI 2 d2)
            (mem/s:SI (plus:SI (reg:SI 1 d1)
                    (plus:SI (symbol_ref:SI ("Nhnr"))
                        (reg:SI 14 a6))))) -1 (nil)
        (nil))
    gcc: Program cc2 got fatal signal 104. (pass2.c)
    make: aborted due to errors
This happens for any processor but -m68000.
Can anybody shed any light?  Can you pass this on to Stephen?
Carl
There is 1 Reply.

#: 18593 S3/Languages
    24-Aug-93  20:25:16
Sb: #18591-#what the *?*{}
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76 (X)
Interesting, I this using the standard Microware assembler/linker?  Or the
Ultra C stuff?
I'll pass it on the Stephen,
  - Mike -
There is 1 Reply.

#: 18599 S3/Languages
    25-Aug-93  22:47:35
Sb: #18593-what the *?*{}
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)
I tried both standard and ucc ... standard complained but ucc didn't about the
tst.l a2, but it didn't even get as far as asm/link on the other problem. BTW,
version 2.4.1 acts just the same.
Carl

#: 18609 S3/Languages
    27-Aug-93  06:37:50
Sb: #BASIC to Assem prob
Fm: JOSEPH CONSUGAR 73007,3264
To: all
I hope someone here can help me with the problem I am having.
I am trying to write an assembly language program that will print a string
passed to it from BASIC09.  The problem I am having deals with the routine
I$WritLn.
I am loading the X register as:     LDX [param1,s] and the Y register as:
LDY len1,s and the path as:                    LDA #1
When I try to call I$Writln with this setup, I get an error #244, which at
first glance, has nothing to do with writing to the screen.
The routine works fine if I reference X and Y to constants located in the data
area, and I still get the error if I specifically load Y with a constant (e.g.
LDY #4).
I my problem with the way parameters are passed from BASIC09 on the stack?  Or
is it some simple thing I am overlooking?
Any help will be much appreciated.
Joe Consugar
There is 1 Reply.

#: 18620 S3/Languages
    28-Aug-93  23:14:29
Sb: #18609-#BASIC to Assem prob
Fm: David Breeding 72330,2051
To: JOSEPH CONSUGAR 73007,3264 (X)
I'm not quite sure exactly what your problem would be, but let me give you some
ideas.
  First, remember that you have a return address on the stack, followed by a
count of the parameters, then each parm is a pair of integer-len variables:
length-of-parm followed by addr-of-parm, or, starting from the bottom of the
stack upwards:
 Retn rmb 2
 Count rmb 2
 LENp1 rmb 2
 addrp1 rmb 2
 lenp2 rmb 2
 addrp2 rmb 2
Also remember that if you are in a subroutine within the program, you have to
take into account the return(s) there OH, I didn't refer to my manual, I MAY
have len & addr reversed, not sure.
One other hint, if you aren't already doing it, although it might not be
necessary, if you are using "asm", I like to enclose the above rmb's within an
"ifp1-endc" pair so as not to include them as data.  If using "rma", I define
them within "csects".
  Let me know if this helps.
Oh, I assume you are using a CoCo?
David
There is 1 Reply.

#: 18627 S3/Languages
    29-Aug-93  11:49:10
Sb: #18620-BASIC to Assem prob
Fm: JOSEPH CONSUGAR 73007,3264
To: David Breeding 72330,2051
David,
    Thanks for your ideas.  I finally found out what I was doing wrong.
    When setting up the entry to I$WritLn, instead of loading X with the
address of the string, what I was doing was loading X with the first two
characters of the string (i.e., ldx [param,s] instead of ldx param,s).
    Felt like an idiot when I finally figured it out.
Joe Consugar

#: 18619 S3/Languages
    28-Aug-93  20:20:04
Sb: false alarm
Fm: Carl Kreider 71076,76
To: all
Well, no one has called me on it yet, so I'll have to fess up all by myself.  I
forgot to take my smart pills the other day....  While "tst.l an" *isn't* legal
on a 68000 and its kin, it *is* legal on the big brothers, 680[234]0.  And my
copy of r68020 was broken.  It should have allowed that instruction.  Most
likely it didn't get updated in the past because of no write permission.  That
still leaves the oil spill from gcc2 as a legit problem, but this one was
cockpit error.
Carl

#: 18995 S3/Languages
    04-Oct-93  22:01:57
Sb: Bug in R63
Fm: David Breeding 72330,2051
To: ALL
TO ALL WHO HAVE DOWNLOADED RMAPAT.AR:
I have been informed of a bug in my patch to "r63".  The tfr's & exg's using
the "W" register did not seem to work.  For a quick fix, change the byte at
offset $179B from $0e to $10..
The new CRC should be $77B166.
If anyone has any more bug reports, please let me know and I will upload a new
patcfile.
..Sorry!!!!
David

#: 18995 S3/Languages
    04-Oct-93  22:01:57
Sb: #Bug in R63
Fm: David Breeding 72330,2051
To: ALL
TO ALL WHO HAVE DOWNLOADED RMAPAT.AR:
I have been informed of a bug in my patch to "r63".  The tfr's & exg's using
the "W" register did not seem to work.  For a quick fix, change the byte at
offset $179B from $0e to $10..
The new CRC should be $77B166.
If anyone has any more bug reports, please let me know and I will upload a new
patcfile.
..Sorry!!!!
David
There is 1 Reply.

#: 19019 S3/Languages
    06-Oct-93  23:01:04
Sb: #18995-Bug in R63
Fm: David Breeding 72330,2051
To: David Breeding 72330,2051
Regarding the patch to "r63"...
   (change byte @ $179b from $0e to $10) If you have uploaded this anywhere,
would you please pass this patch along?
  Also, The CRC above is for an otherwise unmodified version.
David

#: 19149 S3/Languages
    18-Oct-93  14:04:41
Sb: #18591-what the *?*{}
Fm: Frank L. Hoffman 72733,3655
To: Carl Kreider 71076,76
Hi Carl,
  I'm on this here service now, and if you wnat to reply, please do. Just a
reminder, I'm the person with the cross=assembler package VANTAGE, and CRASMB,
and the debugger CRACKER.
  Please let me know if there are any good publications that os9 people get
that I can advertise in.  My voice fone is 503 222-0702 and my fax is 503
222-2334. You should get my compuserve number from this message.
Frank Hoffman, President LLOYD I/O, INC.  Beaverton Oregon USA

#: 19157 S3/Languages
    19-Oct-93  08:25:54
Sb: #19019-Bug in R63
Fm: Wayne Day 76703,376
To: David Breeding 72330,2051 (X)
David,
Were you going to upload a corrected version of the file?
Wayne

#: 19176 S3/Languages
    21-Oct-93  18:25:15
Sb: #19157-Bug in R63
Fm: David Breeding 72330,2051
To: Wayne Day 76703,376
 > David,
 >
 > Were you going to upload a corrected version of the file?
 >
 > Wayne
 >
   Yes, I intend to upload a new, improved, version of the patch.  In
 reviewing the stuff, SEVERAL errors have been found, especially in that
 register usages with W/E-F are not always consistent with those with
 D/A-B.  I think I have them all fixed now.  I am also working on operational
 improvements.  Some things I have fixed so far:
   1.  opt w is functional
   2.  opts were originally designed to be listed more than 1 per line
       such as:  opt l,d55,w60...  anything after a d?? or w?? was treated
       as a comment
   3.  Try opt d55 (or whatever) right after psect with the stock (or my)
       version.
 This is to ALL, really,  It has been suggested that I have r63 to delete
 the ".r" file upon error.  Any comments??  If so, how about an opt "k"(?)
 to override deletion?
 One other thought I have had is to include an opt to accept only 6809-
 compatible code.  It would require some bit of additional coding, but it
 would eliminate the possibility of assembling illegal code if assembling
 for the 6809.  Any thoughts?
 When I get it all fixed, I'll upload a new patch.  Anyone having any comments
 or suggestions is encouraged to do so.
 BTW, Wayne, if you wish, the current file may be deleted, as it is a little
 buggy.  Have you tried this patched "r63"?
                 David Breeding
         ***  Sent via InfoXpress  ***

#: 19343 S3/Languages
    18-Nov-93  20:32:17
Sb: #Ultra ???? C
Fm: Carl Kreider 71076,76
To: ucc gurus
It's been a tough couple days.  My project is out of ram and rom space, but I
figure a better compiler than v3.2 will bail me out.  That will let me use
'const' to keep the menu trees from getting copied from rom to ram, and better
code generation will free up some rom space.  Easy, huh?  Only problem is, gcc
(while it does generate slightly better code) still puts a vsect around the
menu trees and references them off a6, even when they are made const.  About
this time, the new Ultra C arrived.  I got it loaded and patched cc to ucc and
make to umake so it wouldn't collide with the other guys doing development.
Surely ucc will fix me up.  Nope, ucc  generates considerably larger
executables.  Huh??? Yep, about 15% bigger.  The two I was working with are
about 60K and 80K, so they are mostly mine, but the manual (I had *plenty* of
time to read the manuals - ucc is *slow*) says this can happen with the ansi
libraries, so I tweak the makefile again and use -bc for backwards
compatibility. Still bigger.  But I found that I should use -t=0 to force
optimizaton for minimal space, so torch the .r files and try again.  Still
bigger. The best I could do was 5% bigger.  (I almost couldn't compile a couple
files with big state machine switch tables - took 1.8M of free memory after
compiler et al were loaded).
So here is the question for you ucc experts: what is the secret?  What am I
doing wrong?
Carl
There are 3 Replies.

#: 19350 S3/Languages
    19-Nov-93  10:17:17
Sb: #19343-#Ultra ???? C
Fm: Pete Lyall 76703,4230
To: Carl Kreider 71076,76 (X)
Carl -
Which UCC are you using? Allegedly, the 1.1 (a maint release) is supposed to
enhance both compile speed and optimization. Ours has yet to arrive, allegedly
being shipped with our OS9 3.0...
Pete
There is 1 Reply.

#: 19352 S3/Languages
    19-Nov-93  19:17:43
Sb: #19350-#Ultra ???? C
Fm: Carl Kreider 71076,76
To: Pete Lyall 76703,4230 (X)
Using 1.1, the new latest and greatest.
There is 1 Reply.

#: 19369 S3/Languages
    21-Nov-93  21:10:58
Sb: #19352-#Ultra ???? C
Fm: Pete Lyall 76703,4230
To: Carl Kreider 71076,76 (X)
Ugh... that's discouraging. Guess that we will _stay_ with the low tech but
well known V1.4 compiler then.
Pete
There is 1 Reply.

#: 19371 S3/Languages
    21-Nov-93  22:16:08
Sb: #19369-Ultra ???? C
Fm: Carl Kreider 71076,76
To: Pete Lyall 76703,4230 (X)
Or get gcc if you want ANSI.  It uses C3.2 libs and does generate a bit better
code.

#: 19353 S3/Languages
    19-Nov-93  20:04:43
Sb: #19343-#Ultra ???? C
Fm: SCOTT HOWELL 70270,641
To: Carl Kreider 71076,76 (X)
whew!, I thought it was just me!! I was begining to think I'm just a bad 'C'
programmer, well maybe i'm still that!. Anyway YES, I DO get CONSIDERABLY
BIGGER code and a dead-snail's paced compile time and forget about using /r0
for temp files to increase compile time! I downloaded a source on this forum
called 'sc1.c' - scientific calculator which takes 3 minutes to compile on c
3.2 but takes 3 minutes plus a long shower (I could not wait any longer - was
already late for work) for it to tell me that I had ran out of memory - this is
an 80 something 'K' source code. After foregoing '/r0' temp files and unlinking
just about every- thing in memory I finally got it to compile - lets say around
10 minutes or so and about a 15 percent increase in code size. I got so
discouraged that I reinstalled c v3.2. Thank God for the REINSTALL_OLD script
included with Ultra 'C'. I am going to go pick uucc 1.1 next week and I will
see if it improves comp time/code size.
There are 3 Replies.

#: 19354 S3/Languages
    19-Nov-93  20:11:21
Sb: #19353-#Ultra ???? C
Fm: Carl Kreider 71076,76
To: SCOTT HOWELL 70270,641 (X)
Don't count on it - I'm talking about 1.1 here.  I couldn't use 1.0 because it
had to replace v3.2, but ucc1.1 will co-reside (anyone remember cores from
Mot?) with v3.2.
There is 1 Reply.

#: 19357 S3/Languages
    20-Nov-93  00:40:11
Sb: #19354-#Ultra ???? C
Fm: SCOTT HOWELL 70270,641
To: Carl Kreider 71076,76 (X)
Oh well, I setting here listening to by new toy - not a computer, but DMX -
Digital Music Express. Thirty channels of digital music (no commericals or DJs)
ranging from AC to Salsa -what ever that is! Back to OS9 I did try some of the
'time-space knobs', I forgot thr option flags, described in the Manual but did
not find any appreciable code size difference. In fact your code can actually
grow MUCH bigger if you allow maximum loop unrolling. I did a loop (for
(i=0;i<1000;i++) and it unrolled that sucker to nearly 30k or something like
that. Fast, but very big for a 'do' loop that does nothing. I'm definatley NOT
a power user when it comes to 'C', just a novice, so 'C' 3.2 will do me just
fine
There is 1 Reply.

#: 19370 S3/Languages
    21-Nov-93  22:15:11
Sb: #19357-Ultra ???? C
Fm: Carl Kreider 71076,76
To: SCOTT HOWELL 70270,641 (X)
I hear ya!  In fact I think "power user" has little to to with compiler choice.
3.2 isn't ANSI, which would be nice.  But I know where all the caveats are, and
that is worth a ton when you ship product based on that compiler.  As you saw
in my second message, I fiddled the time-space knobs too.  It appears that ucc
might be ok if it had an 'embedded library' that was lean and mean but had
floating point.  3.2 was smaller but had floats.

#: 19355 S3/Languages
    19-Nov-93  20:11:57
Sb: #19353-Ultra ???? C
Fm: Carl Kreider 71076,76
To: SCOTT HOWELL 70270,641 (X)
No ucc power users by here yet, huh?
I have some new info to share.  Contrary to what the manual says, apparently
even in backward compatibility mode you still have to tell it to use word
accesses if that is what you want.  That did help reduce the size of the
executables, but they are still larger than those produced by cc and gcc. The
actual code produced for my program is smaller now by about 6%, but when you
link it against the provided libraries, it ends up bigger.  The difference in
my application appears to be around 8K due to the libraries (and I'm using the
backwards compatibility mode to hold it to that much growth).  There is an
option to use the "small" libraries, but they don't do floating point, so I
would have to write a fixed point math library or something.  Oh, and the
programs run when compiled with cc, but crash with divide by zero when compiled
with gcc and with bus error when compiled with ucc.  Most likely by problem,
but a bit dis-heartening.
Carl

#: 19361 S3/Languages
    20-Nov-93  10:40:20
Sb: #19353-Ultra ???? C
Fm: Zack Sessions 71532,1555
To: SCOTT HOWELL 70270,641 (X)
[Ultra-C Code Size and Compile Time Horror story trimmed]
 > reinstalled c v3.2. Thank God for the REINSTALL_OLD script included with
 > Ultra 'C'. I am going to go pick uucc 1.1 next week and I will see if it
 > improves comp time/code size.
This parallels my experiance with Ultra C V1.0. Unfortunately for me, I
picked up Ultra-C last year on a special deal which Microware was offering.
I paid $499 for it, I understand the regular price is $999. I called my
Microware salesman a few weeks ago and found that a V1.1 upgrade would
cost me $395!!!!! I guess that is a good price if one paid $999 for V1.0,
but it sucks for me to have to pay just $100 less than what I paid for the
original just to get an upgrade. An upgrade which sounds like does not
fix the original problems. That is, consistently larger binaries and
much longer compile times, and for what?
------------------------------------
 Zack C Sessions
 ColorSystems
 "I am Homer of Borg, prepare to be assimi ... OOOOHHH, DOUGHNUTS!"

#: 19377 S3/Languages
    22-Nov-93  20:47:20
Sb: #19343-Ultra ???? C
Fm: Bob van der Poel 76510,2203
To: Carl Kreider 71076,76
I assume that you have reviewed the "ultra c application notes" 02/93 from MW?

#: 19383 S3/Languages
    23-Nov-93  21:33:52
Sb: #19377-Ultra ???? C
Fm: Carl Kreider 71076,76
To: Bob van der Poel 76510,2203 (X)
Can't say as I have seen them.  Can you highlight anything pertinent?

#: 19384 S3/Languages
    23-Nov-93  21:41:59
Sb: #19343-Ultra ???? C
Fm: Carl Kreider 71076,76
To: Carl Kreider 71076,76 (X)
Ultra C definately generates the smallest code, if you don't use any libraries.
But, in real life.....  I haven't found why the ucc compiled code bus traps,
but I did find why the gcc compiled code died with 107 - it is blowing all the
floating point stuff.  I can't believe I am the only one to ever do floating
point, so what am I doing wrong?  I don't have a 68881 in the target, so need
the emulation.  A test program works with 1.37.1, but not on 2.4.1 or 2.4.5
(either July or Oct releases). Any ideas anyone?
Carl

#: 19420 S3/Languages
    04-Dec-93  21:15:47
Sb: #19384-Ultra ???? C
Fm: Carl Kreider 71076,76
To: Carl Kreider 71076,76
Well, I answered my own question.  Stephan says that 2.4.5 had a bug.  It is
now fixed in the latest upload to cabrales.

#: 19423 S3/Languages
    05-Dec-93  01:11:29
Sb: #r63 upload
Fm: David Breeding 72330,2051
To: Sysop* (X)
I have just uploaded a new version of the patch for rma which enables it to
assemble 6309 code.  The filename I uploaded it under is "r63v13.ar".  However,
I made 2 attempts to upload under Cis-B protocol, and apparently it aborted (on
CIS's end??).  Anyway, I finally attempted it under X1k, and it completed, but
I tried to do so under the same name all 3 times, and I'm not sure if CIS
deletes an aborted file.  The original file length was 48762 bytes.  The ar
file contains 2 files, rma13.ipc (41799 bytes) and r63.doc (8699 bytes),
original lengths.
  If the file is bad, let me know and I'll try it again.
Thanks
David
There is 1 Reply.

#: 19427 S3/Languages
    05-Dec-93  11:15:16
Sb: #19423-r63 upload
Fm: Steve Wegert 76703,4255
To: David Breeding 72330,2051
David,
Your transactions came through just fine and are merging into the library as I
type this reply.
Thanks for the extra effort in uploading your file ... and sorry for the
hassle!
Steve

#: 19420 S3/Languages
    04-Dec-93  21:15:47
Sb: #19384-Ultra ???? C
Fm: Carl Kreider 71076,76
To: Carl Kreider 71076,76
Well, I answered my own question.  Stephan says that 2.4.5 had a bug.  It is
now fixed in the latest upload to cabrales.

#: 19423 S3/Languages
    05-Dec-93  01:11:29
Sb: #r63 upload
Fm: David Breeding 72330,2051
To: Sysop* (X)
I have just uploaded a new version of the patch for rma which enables it to
assemble 6309 code.  The filename I uploaded it under is "r63v13.ar".  However,
I made 2 attempts to upload under Cis-B protocol, and apparently it aborted (on
CIS's end??).  Anyway, I finally attempted it under X1k, and it completed, but
I tried to do so under the same name all 3 times, and I'm not sure if CIS
deletes an aborted file.  The original file length was 48762 bytes.  The ar
file contains 2 files, rma13.ipc (41799 bytes) and r63.doc (8699 bytes),
original lengths.
  If the file is bad, let me know and I'll try it again.
Thanks
David
There is 1 Reply.

#: 19427 S3/Languages
    05-Dec-93  11:15:16
Sb: #19423-r63 upload
Fm: Steve Wegert 76703,4255
To: David Breeding 72330,2051
David,
Your transactions came through just fine and are merging into the library as I
type this reply.
Thanks for the extra effort in uploading your file ... and sorry for the
hassle!
Steve