randyh@hpsad.HP.COM (Randy Hosler) (09/12/90)
I need some help with a problem. The following source fragment is for
MEGAMAX C. I'm trying to compile it with Sozobon and it barfs on this
asm code. Could some kind soul show me how to get Sozobon to accept
this code. The var 'program' is a pointer to char.
thanks alot, Randy
------------------------------------------------------------------------
asm {
movem.l A6-A4,-(A7)
move.l program,-(A7)
jsr 0x32(program)
move.l (A7),program
jsr 0x88(program)
move.l (A7)+,program
movem.l (A7)+,A4-A6
}
------------------------------------------------------------------------fk@vall.dsv.su.se (Fredrik Kilander) (09/13/90)
In article <18420003@hpsad.HP.COM> randyh@hpsad.HP.COM (Randy Hosler) writes: >I need some help with a problem. The following source fragment is for >MEGAMAX C. I'm trying to compile it with Sozobon and it barfs on this >asm code. Could some kind soul show me how to get Sozobon to accept >this code. The var 'program' is a pointer to char. [lines deleted] > movem.l A6-A4,-(A7) > move.l program,-(A7) [lines deleted] >------------------------------------------------------------------------ In my experience Sozobon's asm will only accept lowercased symbols for register names. Remember that it is not a full assembler but targeted to assembling output from the compiler. Why this should prevent it from understanding either a3 or A3 I don't know. Btw, I've come across a bug in asm which may be fixed by now. It concerns the btst instruction which compiles into 4 bytes when it should be 6 (or possibly the other way around, my memory is a bit dim on this). Anyway, if anyone knows for certain how to obtain fresher code or a patch, I'd appreciate an email to this effect. =============================================================================== Fredrik Kilander, Dpt. of Computer and Systems Sciences, Stockholm University Internet: fk@dsv.su.se Voice: +46 8 16 45 00 Fax: +46 8 703 90 25 =============================================================================== -- =============================================================================== Fredrik Kilander, Dpt. of Computer and Systems Sciences, Stockholm University Internet: fk@dsv.su.se Voice: +46 8 16 45 00 Fax: +46 8 703 90 25 ===============================================================================
steve@thelake.mn.org (Steve Yelvington) (09/13/90)
[In article <18420003@hpsad.HP.COM>,
randyh@hpsad.HP.COM (Randy Hosler) writes ... ]
> I need some help with a problem. The following source fragment is for
> MEGAMAX C. I'm trying to compile it with Sozobon and it barfs on this
> asm code. Could some kind soul show me how to get Sozobon to accept
> this code. The var 'program' is a pointer to char.
>
> thanks alot, Randy
>
> ------------------------------------------------------------------------
> asm {
> movem.l A6-A4,-(A7)
> move.l program,-(A7)
> jsr 0x32(program)
> move.l (A7),program
> jsr 0x88(program)
> move.l (A7)+,program
> movem.l (A7)+,A4-A6
> }
> ------------------------------------------------------------------------
I'm not sure what this fragment does, but....
Embedded assembly isn't a defined feature of the C language -- it's
implementation-dependent. Sozobon was written to be compatible with
Alcyon C, which uses this syntax:
asm("mnemonic arg1,arg2");
Sozobon & Alcyon also prepend an underscore to C identifiers to avoid
collisions with labels used in pure assembly modules. Thus your asm
fragment would look like this, assuming "program" is defined in your
C code as "char *program" or the equivalent:
asm("movem.l A6-A4,-(A7)");
asm("move.l program,-(A7)");
asm("jsr 0x32(_program)");
asm("move.l (A7),_program");
asm("jsr 0x88(_program)");
asm("move.l (A7)+,_program");
asm("movem.l (A7)+,A4-A6");
A7 also may be referred to as "sp" (for stack pointer).
Beware that some code prepared for Megamax/Laser C may contain
capitalized asm mnemonics, etc., that Sozobon won't like.
Another way to port this code would be to write the function in
assembly and include the .S file in the command line to CC.TTP.
Also, Tony's optimizer chokes on some weird assembly language, notably
anything having to do with Line A. Such modules have to be assembled
separately into .O files, then linked, as in:
cc -o test.tos test.c fubar.c linea.o
--
Steve Yelvington up at the lake in Minnesota
(moving soon to Marine on St. Croix)
steve@thelake.mn.org plains!umn-cs!thelake!stevefranky@netmbx.UUCP (Frank Bergemann) (09/14/90)
In article <18420003@hpsad.HP.COM> randyh@hpsad.HP.COM (Randy Hosler) writes:
]I need some help with a problem. The following source fragment is for
]MEGAMAX C. I'm trying to compile it with Sozobon and it barfs on this
]asm code. Could some kind soul show me how to get Sozobon to accept
]this code. The var 'program' is a pointer to char.
]
I had the same problem with including asm-files inC-source-text.
It works, if you include evry single assembler line in
asm (" assembler-code ") ;
don't ask me why including a packet of lines doesn't work.
i also hope the authors of sozobon will change this.
i wrote a programm which converts a asm-source to an acceptable
format for sozobon.( it reads a line from an input-file, and outputs
Print #1; " asm ("; chr$(asc(")); line$; chr$(asc("));") ;"
its a terrible basic-schotter, but i hope you see what i mean....
...Franky.............archbold (Archie Jaszcz) (09/15/90)
> Another way to port this code would be to write the function in > assembly and include the .S file in the command line to CC.TTP. > > Steve Yelvington up at the lake in Minnesota That's a feasible thing to do, but if you have an assembler that will compile it's code into *.O files, you can do it too. I found that all labels in assembly code which are required by the other *.O code written in C should begin with an underscore '_' (otherwise C compiler gives a message such as "symbol(s) missing: (whatever)"... I've done such things as described above for my bro when he couldn't get some stuff accomplished in C and needed me to write it in assembly... Worked every time. Archbold
randyh@hpsad.HP.COM (Randy Hosler) (09/17/90)
Hi all,
First I would like to thank everyone who made suggestions via e-mail or
replied to this note. I got the code to compile :-) , however, it
doesn't do what I had hoped. (more about that later)
In order for it to compile I re-wrote the code as below. The other
change I had to make was to the variable "program". It was originally
declared a register char *program. When I compiled the code with the -S
option and then looked at the source file I couldn't find _program
anywhere accept in the asm fragment. After declaring program as a global
above main() the code would compile because it now had a reference for
_program. I don't know if everyone followed that, but I had a great time
figuring it out. This is what the fragment now looks like.
asm("movem.l a4-a6,-(sp)");
asm("move.l _program,-(sp)");
asm("jsr $32+(_program)");
asm("move.l (sp),_program");
asm("jsr $88+(_program)");
asm("move.l (sp)+,_program");
asm("movem.l (sp)+,a4-a6");
This code is part of a program that makes use of routines in
stspeech.tos to produce speech from text while bypassing the prompts
of stspeech.tos. I have a program called speech.tos that I thought was
the same thing as stspeech.tos but apparently is not. If anyone has
stspeech.tos or has written a program that interfaces to the speech
routines of speech.tos please let me know. I would like to write some
programs for my chidren that incorporate speech.
Thanks alot,
Randy randyh@hpsadpkarchbold (Archie Jaszcz) (09/18/90)
randyh@hpsad.HP.COM (Randy Hosler) writes: > change I had to make was to the variable "program". It was originally > declared a register char *program. When I compiled the code with the -S > option and then looked at the source file I couldn't find _program > anywhere accept in the asm fragment. After declaring program as a global > above main() the code would compile because it now had a reference for > _program. I don't know if everyone followed that, but I had a great time > figuring it out. This is what the fragment now looks like. > The reason you couldn't get a reference of _program was just what you wrote: it was not a global variable. When I first looked at a simple dissassembled *.O file, I was surprised to see that main() does a LINK instruction in assembly. In other words, all variables declared in main() are simply going to be temporary as they exist only on stack, and not in real GEMDOS data area. I think in object files you can only get references to procedures and global variables (although I MAY be wrong), since local variables are just offsets on a stack... I don't know if all of this made sense... Archbold
tony@raid5.uucp (Tony Andrews) (09/21/90)
In article <6V0oP2w163w@bluemoon.UUCP> archbold (Archie Jaszcz) writes: >randyh@hpsad.HP.COM (Randy Hosler) writes: >> After declaring program as a global >> above main() the code would compile because it now had a reference for >> _program. I don't know if everyone followed that, but I had a great time >> figuring it out. This is what the fragment now looks like. >> > The reason you couldn't get a reference of _program was just what >you wrote: it was not a global variable. When I first looked at a simple >dissassembled *.O file, I was surprised to see that main() does a LINK >instruction in assembly. In other words, all variables declared in main() >are simply going to be temporary as they exist only on stack, and not in >real GEMDOS data area. I think in object files you can only get >references to procedures and global variables (although I MAY be wrong), >since local variables are just offsets on a stack... There's nothing special about the function "main" in C except that it is the first function called, and it receives the command line arguments. Variables declared in main() go on the stack just as in any other function. Accessing local variables via embedded assembly is a bit of a pain in general because they are referenced via offsets from the frame pointer (in a6). At the request of some of our users we added a feature in version 1.2 to make this a little easier. The output of hcc now includes a comment block at the start of each function that shows all local variables and their offsets. --tony -- Tony Andrews uunet!dunike!onecom!raid5!tony Array Technology Corp. 4775 Walnut St., Suite B Boulder, Colorado 80301 USA
archbold (Archie Jaszcz) (09/26/90)
tony@raid5.uucp (Tony Andrews) writes: > There's nothing special about the function "main" in C except that it is > the first function called, and it receives the command line arguments. > Variables declared in main() go on the stack just as in any other function. > Accessing local variables via embedded assembly is a bit of a pain in > general because they are referenced via offsets from the frame pointer > (in a6). > > At the request of some of our users we added a feature in version 1.2 to > make this a little easier. The output of hcc now includes a comment block > at the start of each function that shows all local variables and their > offsets. > > --tony Tony! I know that about the main() function now... It is just that I wasn't too much into C, I'd rather do stuff in assembly. Anyways, I stumbled across the finding when I looked at dissassembled *.O file which of course had main() and main would do a link a6,#0 (or -something if it had any arguments). It was surprising to me, because I never thought of main() as being just an ordinary function... Archbold osu-cis!n8emr!bluemoon!archbold Disclaimer: I haven't seen Veronica lately!