What I wanted out of the master code for now was to get the CP/M Plus booted off the IDE (CF).
I agree that contemporary C compilers, and intelligent use of C can produce code almost as compact
as hand written assembler. My concern was that stack frame maintenance, startup code size, alignment
and minimum library inclusion carries some overhead in the code segment.
I assume you do the first few steps in assembler with the board in the freezer for the ice scream part
of the bring-up, then thaw it out once serial output is functional so it can start telling you how it feels.
When I started writing in C, I kept the assembler output listing file enabled while I learned what C
constructs generated the most efficient code. Then I pretty much stuck to those. I agree C is portable
assembly language, and I do try to write platform agnostic C code, isolating platform dependencies
in assembler bindings where necessary. Some of the C compilers I have been using to generate code
for the Z80 are vintage and as such do not have contemporary optimizations. Beyond that, compilers
such as Aztec are pre-ANSI and painfully K&R-ish. That is one of the reasons I have been trying to get
N8VEM builders interested in SDCC, so I can get the heck out of K&R land.
Cross platform C code though of course must allow for the change in endian orientation. I am sure
you are dealing with that in your 68XXX port.
I look forward to working with you on cross platform utilities where possible. All my RomWBW
utility C code is in a sub-folder of the Apps folder in RomWBW. Help yourself when you like.
On 1/26/2013 7:04 PM, yoda wrote:
Oh - my mistake. My approach was to build the monitor from the opposite direction. Instead of dropping code I start with a new file and add just enough code to get the serial port working. My basic first step is to get sending characters out in a loop which I call the scream test. This can be done with all code in ROM and not using RAM which is the critical first step as you don't know you have working RAM yet. Next I add the code to check the memory and find the TOP of RAM. This allows you then to set a stack pointer and use subroutines. If you look on John's pages there is a RAM test program that uses no subroutines that is all in line code so it will execute from ROM using no RAM - get this running with your serial I/O routines (you will have to modify it some because he does not use the serial I/O card, but it is not hard). Once you have that all working then you can start cutting and pasting code from John's monitor code and implement one function at a time and test it. I know it is kind of tedious but you can rapidly build up the monitor with the functions you need. I find some of the routines he provides not entirely useful so I did not bring those over.