Re: Aztec C and Dosemu

Bill Buckels wrote:
"Michael J. Mahon" <mjmahon@xxxxxxx> wrote in message news:KYydnRtKbPtKP-rVnZ2dnUVZ_trinZ2d@xxxxxxxxxxxxxx

1. The Aztec C native mode compilers are dog-slow and brutal (almost
impossible) to configure the way we use compilers today and disk swapping,
lots of typing, etc. is required. It's way too much work.

Bill, is this still the case when running from a hard disk installation
with an accelerator? Most developer's Apple II's today are pretty well
decked out. ;-)

Mine isn't though. It doesn't have a hard disk or a zip chip. If a guy is lucky enough to have an Apple II that isn't dog-slow and copies all the Aztec C stuff into one directory then it would likely be doable. I am using some of my pin money to get a GS but maybe I should also grab an accellerator of some kind for the //e and a HD as well and try it out. What would you recommend? I had a 5 MGHZ zip chip on my now-vanished original //e in 1992.

I use an 8MHz Zip Chip and a CFFA with four 32MB ProDOS partitions in my
//e development system. The Zip Chips are hard to come by these days,
but they show up on eBay every so often, and tend to go for $100-$200.
;-( The CFFA is available for about $100 and is a "must have" in my
book, not only for the self-contained "hard drive", but for the very
easy and convenient demountable "disk" for backup and file transfers
using CiderPress.

And many of them work on emulated Apple II's that run at 50MHz or so...

I think the Cross-compiler running in a Windows cmd window on a DX 64/3000 which is almost instantaneous is the bext way to go. This is just me though.

I like a *little* delay--it annoys me to think that the computer can
process all my hard-won code before I can move my finger. ;-)

I'm not a big fan of cross-development when the target system can be self-supporting--just a personal preference.

Mine is just a personal preference too. I am reliving my past with Aztec C cross-compilers from the comfort of a fast computer and just relaxing. I never bothered with native mode development on the Apple //e and have a couple of decades into using this cross-compiler if you count the 15 year gap when it sat on the shelf:)

Ah. And I view the //e as a completely self-supporting programming
environment.

Structured code can be written in any language--as can unstructured
code. I find my style of BASIC quite readable and modifiable, even
years later (by which point, it's like a program written by someone
else ;-).

It's whatever you are comfortable with as with anything. A C program is much prettier to me and much more readable. Upper case hurts my eyes:) Any comparison between an Applesoft program being considered structured and a C program that is structured would be in the eyes of the beholder IMO.

Structure is pattern. It makes things look like what they do.
All such perception is learned.

The one thing I most miss in Applesoft is explicit procedures with
parameters (though my GOSUB discipline is pretty good).

This was a start. My work with compiled basic and procedural basic dates back to the mid-80's and I lost the line numbers as quickly as I was able to. GoSub LabelName quickly vanished into library routines of type SUB or FUNCTION. The Visual Basic that I use in Visual Studio 2005 is prettier than Applesoft too. But even I see the beauty in a well-written Applesoft BASIC program simply because it is part of my history.

Line numbers don't bother me at all. They are just like the line
numbers in legal briefs. ;-)

One other benefit that C compilers have is that the core routines are
written in assembler and even though they are stack based they are quick so machine language is generally not necessary to speed-up the program.

I can see that that would eliminate the need for much assembly code,
except where cycle counting is involved.

Aztec C supports inline assembly and the linking of assembly language modules if one needs to.

As I would expect.

For me, assembly language is an invitation to match the data structures
and the register allocation to the hardware, so that things that would
take 20 instructions in compiled code take less than 10--sometimes much
less. I have no problem using a register for a loop variable or setting
up a table so that single-byte links can be used--things unheard of in
compiled languages. For me, a frequent assignment statement would be
translated as "TXA"!

I find that the canonical data structures of higher-level languages are
often quite inefficient for an 8-bit machine.

One of the nicer features of any compiled language is that comments do
not take memory space!

I comment more than I code. Short novels are written in my programs:) It is really very hard for me not to write comments.

That's my style for compiled languages, as well.

Like Dijkstra, I regard the code itself as less than 10% of the program.

A big concern that I have about starting to use C (of any flavor) in my
Apple II programming is whether I would have sufficient control over
memory allocation (particularly for the run-time). I integrate lots of
assembly code into my programs, and use lots of dynamically allocated
buffers, while dodging hi-res pages, string pools, etc. It's a huge
benefit of Applesoft that the "run-time" is in ROM. ;-)

C is all about control memory allocation and the overlay feature of Aztec C pages the runtime in and out as required by specific modules. Also the BASIC ROM routines are not used.

Of course, not using something that's always there is not necessarily
a virtue. ;-) I do realize that I could map the ROM out and get
another 8KB or so of RAM, but most run-times I've seen are about that
big or worse (much of it devoted to 16-bit integer arithmetic, which
I am expert at minimizing).

Actually, the amount of RAM used by C vs. Applesoft is a major concern.
How does it stack up?

I'm interested in the possibility of using C to replace big chunks of
Applesoft that I use to launch, control, and generally glue together
programs, but I'd hate to get "up to speed" and find that I can't
actually make it work--because of memory consumption, allocation
conflicts, etc.

Anyone (programmer) can make it work I think. Given the will and the time to do so. My thing is that I already made it all work and I am trying to provide a clear approach that someone else can follow. Only time will tell if I succeed in doing so.

It won't work if it takes more RAM than I have available!

I generally exploit the fact that "90% of the execution time of a
program is spent in less than 10% of the code" to make the complicated
but performance-irrelevant parts in Applesoft and the time-consuming
parts in assembly language, and I find it generally quite effective.

It is, I've done that too, and if you are happy with it this method then that is what counts. Most days lately I couldn't be happy unless I wrote the whole thing in C without all the mixing of the laguages.

Mixing would always be necessary for me, since I require "on the metal"
data structures. Two is the smallest number of things that can be
mixed, so that doesn't bother me. ;-)

I have decades (!) of experience dealing with these issues using
Applesoft, and no experience with Aztec or other C. And these topics
are sufficiently obscure that they are seldom discussed, so it's hard
to know what problems I will have to solve...

All this is true and represents the other side of the argument perfectly. A person stays with a programming tool or a language and develops a wealth of experience in that. There is no reason to change and I have decades in C and wouldn't change if I didn't need to.

Still, I'm considering giving it a try...

-michael

AppleCrate: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Relevant Pages

  • Re: C Compilation..
    ... machine's assembly language instead. ... Most C statements map quite naturally to only a few assembler instructions. ... Theoretically you could also have a bad C compiler, but in practise such compilers aren't released. ...
    (comp.lang.c)
  • Re: Compiler
    ... A good book on programming language implementation is Samuel Kamin's ... "Programming Languages: an Interpretter-Based Approach". ... starts talking about compilers, too. ... you need to be sure you know how assembly language works. ...
    (comp.lang.asm.x86)
  • Re: ANSI C compliance
    ... One of the world's most used C compilers, gcc, has a command line ... But it has nothing to do with the C language, ... > platform might not work on another platform. ... Chars have 8 bits and plain char is signed. ...
    (comp.lang.c)
  • Re: new IL: C (sort of...).
    ... I have considered deprecating typedef (the reason is that typedef adds a ... and to the Algol-like language concepts. ... of ancient C compilers, like Small C, which could compile the output of ... now LLVM has them, so it is a lot more of an issue. ...
    (comp.lang.misc)
  • No Starch Press Releases "Write Great Code, Volume 2"
    ... Thinking Low-Level, Writing High-Level ... Explains how compilers work and how to get the best quality output from ... code for those high-level language statements and data structures, ... In the early days of computing, programmers used high-level language code ...
    (comp.os.linux.announce)