peter@aucs.UUCP (08/26/87)
In version 1.0 of LSC (I never received an upgrade?), the assembler
interface was very poor, no inline, no assembler provided, nothing
but a routine to convert MDS rel files to be capatible with LSC rel
files. What is provided in the current LSC 2.11 version for using
assembler?
Peter W. Steele UUCP : {uunet|watmath|utai|garfield}!dalcs!aucs!Peter
Acadia University BITNET : Peter@Acadia
Wolfville, N.S. Internet : Peter%Acadia.BITNET@WISCVM.WISC.EDU
Canada B0P 1X0 PHONEnet : (902) 542-2201x121singer@endor.harvard.edu (Andrew Singer) (08/27/87)
In article <418@aucs.UUCP> peter@aucs.UUCP (Peter Steele) writes: >In version 1.0 of LSC (I never received an upgrade?), the assembler >interface was very poor, no inline, no assembler provided, nothing >but a routine to convert MDS rel files to be capatible with LSC rel >files. What is provided in the current LSC 2.11 version for using >assembler? Version 2.01 of LSC introduced an inline assembler capability. It's worth noting that this is not your standard "pass this text through to the assembler pass" type of inline assembly (which we couldn't do anyway, since there is no assembler pass). Inline assembly is fully integrated into the compiler via a new C statement of the form: asm { ;Insert your assembly language statements here } Since the inline assembler is integrated, you can directly reference C functions and variables by name and it will assemble into the appropriate A5 or A6 relative reference. If your assembly code is imbedded in a C 'for' statement, you can still use 'break' and 'continue', and you can always use 'return'. #define'd identifiers are honored. And so on. There are lot's more details, of course, but I think you get the general flavor... Jon Hueras THINK Technologies, Inc.
sdh@faline.bellcore.com (Steve Hawley) (08/27/87)
In article <> peter@aucs.UUCP (Peter Steele) writes: >In version 1.0 of LSC (I never received an upgrade?), the assembler >interface was very poor, no inline, no assembler provided, nothing >but a routine to convert MDS rel files to be capatible with LSC rel >files. What is provided in the current LSC 2.11 version for using >assembler? if memory serves me, you just do this: asm { /* your assembly language here */ } This can go wherever a valid c statement can go. Good luck. Steve Hawley "Thanks Ken Buddha -a smile, 2 bangs, and a religion."
stevem@hpvcla.HP.COM (Steve Miller) (09/02/87)
> Version 2.01 of LSC introduced an inline assembler capability. It's worth > noting that this is not your standard "pass this text through to the > assembler pass" type of inline assembly (which we couldn't do anyway, since > there is no assembler pass). Inline assembly is fully integrated into the > compiler via a new C statement of the form: > > asm { > ;Insert your assembly language statements here > } I'm not familiar with in-line assembly so I am curious: Does the programmer know what registers have what values (epsecially when using register variables) or does the programmer just save all registers that are to be used by the assembly code and restore them at the end? Steven Miller
singer@endor.harvard.edu (Andrew Singer) (09/04/87)
In article <3770004@hpvcla.HP.COM> stevem@hpvcla.HP.COM (Steve Miller) writes: >I'm not familiar with in-line assembly so I am curious: Does the programmer >know what registers have what values (epsecially when using register >variables) or does the programmer just save all registers that are to be >used by the assembly code and restore them at the end? > >Steven Miller I'll give you a quick example: foo() { register char *p; asm { move.b (p)+, d0 } } Here, p would be assigned to an address register, the entry code to foo will save the contents of that register, and the exit code will restore the register. Note that this has nothing to do with inline assembler. This is the way LSC normally works. What's unique about LSC's inline assembler here is that, being integrated into the compiler, it knows that p is a register variable and you can use p in any assembler context where a register name is required. Jon Hueras THINK Technologies, Inc.