Attn: C80 experts, help needed...

[Joe Travis N6YPC]

After a 35+ year absence from C80 and 8080 ASM, I thought it may be therapeutic for me to dive back in.  I started just a few weeks ago to build up a library of software tools for C80 and have encountered a couple problems I have yet to resolve.  I'm hoping someone in the group may be able to offer some solutions.  TIA!

#1.  How can I pass the address of a function in a function?  For example: pokew(addr, &function()).  I've tried using &function() along with various other incantations which don't seem to work.  C80 will usually complain it needs a "lvalue" when compiling.  Regardless if it complains or not, the code generated is always:

... CALL  function

    PUSH  H

    CALL  pokew...

When it really should be:

... LXI  H,function

    PUSH  H

    CALL  pokew

For those who wish to dig in, I'm including my files.  For problem #1 please look at h84lib.c, line number 119.

#2.  I've written an ISR using inline assembly language and need access to certain C variables.  I use the C variable labels in the assembly language portion however, the compiler doesn't care and generates it's own names (.d, .e, .f, etc.) for the labels.  I could go into the ASM/MAC file and edit them to work but, I hope/believe there's a better way.  The ISR is also located in the h84lib.c file.

BTW - I ultimately plan to release these libraries to the group github page once they have been thoroughly tested.  Thanks again for your help.

Regards,

Joe Travis n6ypc

[Douglas Miller]

Here's what worked for me:

#1: I just reference the function name without "()" and without "&" (as done for modern C). For example, this (nonsense) code produced the correct ASM:

extern int func1();

foo() {
        int *f;
        f = func1;
        *f = 0xedb0;
}

#2: I'm not seeing any issue - the ASM file contains the same labels as in the #asm section of the C source ("ISR000", etc). One thing about most C compilers of that era (and even modern ones) is that "C" variables, etc, will be prefixed with a special character internally ("_" if it's valid) which means that any inline assembly language must manually prefix references to C variables, etc. If you have a C variable "foo" you must refer to it as "_foo" from inline assembly code (or whatever the special character is for your assembler config).

Maybe we're not talking about the same "C80"? I'm using "The Software Toolworks C/80" on CP/M.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9bcf6f43-320c-46bd-a8d9-d8373917f76en%40googlegroups.com.

[Douglas Miller]

I misspoke about C/80 prefixing variables. C/80 does not prefix global variable names with anything.

Perhaps you are talking about how C/80 treats local variables vs. global variables? Only global variables are assigned "meaningful" labels, basically the name used in the program source code. Local variables are always rendered/renamed into temporary labels. You can really only reliably access global variables from ASM code. Although, there was a trick we used to pass a single local variable into ASM code: if you have a seemingly useless statement "var;" immediately before your "#asm" you can assume the HL will contain the value of "var". It's a bit of a kludge, but can be used.

[Joseph Travis]

Thanks for your help Doug, both problems are resolved.  The extern declaration fixed the issue regarding passing the address of the function.  The other issue was caused by declaring the C variables as static.  Once I removed that, the labels popped up in the assembly language output of the compiler.  Thank you!

Regards,

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b2942666-1c0d-0094-9cb7-cca654a31331%40gmail.com.

[Glenn Roberts]

Sounds like you’ve gotten an answer joe. But FYI I’ll remind you all of cdecl which is a very useful resource

 

https://cdecl.org/

 

so “declare x as pointer to function returning int” results in:

 

int (*x)()

 

you can then pass x, store in an array, or otherwise use it like any other variable.

 

also of course if you’re working with C/80 I highly recommend keeping a copy of Kernighan & Ritchie (“K&R” – the original 1978 one, not the later ANSI one) by your desk.  Pointers to functions are discussed in 5.12, see especially the sort() routine on p. 116…

 

Joe: did you get the answer on how to connect your ISR globals to your C program?  I can help with that if you still need it…

 

 

• Glenn

--

[Joseph Travis]

Hi Glenn,

Thanks for the info on cdecl, very interesting.  Doug's suggestion solved the issue regarding passing the address of a function.  The C variables not seen by the assembly language ISR routine was caused by declaring the variables as static.  Once I removed "static", the compiler generated the correct labels which the inline assembly language now sees.

It all compiles / assembles fine although I rediscovered the name size limitation in M80 and will have to pay close attention to naming conflicts.  For example: h84putc and h84puts conflict due to the first 6 characters being the same.  I seem to remember early version(s) of M80, the limitation was only 5 characters.

Believe it or not, I still have my original first edition K&R and used it as the source for some of the functions in adlib.c.  I used to have a copy of the ANSI version but gave it away (loaned to someone but never returned).

I'm proceeding to test everything now.  So far, so good.

Joe

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/6X3LGHpFlq8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/0b6901d8cf4e%244c9e2160%24e5da6420%24%40gmail.com.