kenny@uiucdcsb.cs.uiuc.edu (04/28/87)
/* Written 12:50 pm Apr 24, 1987 by stuart@bms-at.UUCP in uiucdcsb:comp.lang.c */
/* ---------- "Re: C vs assembler, or, Here We Go" ---------- */
[...] our people can still turn out a full featured data
entry program using assembler in only 15 minutes as opposed to 2
hrs for 'C'. The difference is that our 'C' library has not
evolved to the extent that the assembler library has. (An
assembler data entry program consists of some table definitions
via macros and some subroutine hooks to implement deviations from
standard features.)
--
Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
/* End of text from uiucdcsb:comp.lang.c */
Sounds as if what you need is a set of interface adapters to make your
assembler library callable by C programs. And, speaking from
experience, it is astounding what improvements in productivity can
result by making an existing mature library available to any ``new''
language; not only does it make all the existing functions available,
but it also means that the programmers can apply what they know about
the old library's quirks.
Moral: Choose a run-time environment that allows interlinking all your
languages.
Kevin Kenny UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny
Department of Computer Science ARPA: kenny@B.CS.UIUC.EDU (kenny@UIUC.ARPA)
University of Illinois CSNET: kenny@UIUC.CSNET
1304 W. Springfield Ave.
Urbana, Illinois, 61801 Voice: (217) 333-8740stuart@bms-at.UUCP (Stuart D. Gathman) (05/03/87)
In article <165600001@uiucdcsb>, kenny@uiucdcsb.cs.uiuc.edu writes: > > hrs for 'C'. The difference is that our 'C' library has not > > evolved to the extent that the assembler library has. (An > Sounds as if what you need is a set of interface adapters to make your > assembler library callable by C programs. And, speaking from Ahhh, you miss the point. The C programs run on (many) different machines than the assembler code! Portability was one of the advantages I pointed out for 'C'. The assembler code runs on IBM Series/1 minis under EDX only. Our 'C' code runs on any Unix box with little effort, and even in EDX with major library work. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
hamilton@uxc.cso.uiuc.edu (05/08/87)
jda@mas1 (James D. Allen) says: > First penny) > Some control flow techniques -- in particular coroutine > linkage -- are inconvenient in C but achieved elegantly in assembly. > To avoid a proliferation of global variables > and/or "gotos" I have seen multitasking: > ... > used where an assembly language programmer would have invented > coroutines even if he'd never heard of them. Admittedly > the multitasking design may be more readable; the point is > that the assembly-level option is not readily available in C. Version 6 Unix C _had_ coroutines. as it happens, i was hunting for them just recently. i found my old manual pages, but i can't find an old enough tape around here to look for the sources. coroutines were implemented in a manner that paralleled fork's and pipe's, making them very natural in a Unix context. > Second Penny) > #define DSK_SEL *(char *)0xf12345 /* WRITE but dont READ */ > DSK_SEL = 0; > caused a parity error and had to be replaced with > temp = 0; DSK_SEL = temp; > The code generated was CLR.B and MOV.B respectively. Can anyone > elucidate? check your 68000 processor manual. under "CLR", it points out: "a memory destination will be read before it is written to". wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton