Groups > comp.sys.apple2.programmer > #1027

Re: Suggestions for improving speed of .SYS program.

From	"Bill Buckels" <bbuckels@mts.net>
Newsgroups	comp.sys.apple2.programmer
Subject	Re: Suggestions for improving speed of .SYS program.
Date	2014-01-01 14:44 -0600
Organization	Aioe.org NNTP Server
Message-ID	<la1uni$bnt$1@speranza.aioe.org> (permalink)
References	<la0kks$qcu$1@news4.open-news-network.org> <b7597448-6d38-4a44-a4eb-a61bbc2f5707@googlegroups.com> <la1q0p$afb$1@news4.open-news-network.org>

Show all headers | View raw

"Matt" <matt@clickertraining.co.nz> wrote:
>Thanks very much for looking at this :-)

I looked at it too, moved some lines around, then abandoned it, not even 
bothering to save... so I have the source here and see many nested loops (4 
levels) and structures in use. One big buffer would be a place to start with 
afew pointers. Keeping in mind that like the others in here, I seldom 
sleep... and I have a calculator in my hand and a peeks and pokes chart on 
the wall at all times.

The style is too high level for my taste and reminiscent of modern 
compilers.

I hardly think that optimizing in ML is the way to go right now, but I 
haven't the time to make this work quickly right now either. My own projects 
are more important to me.

Aztec C outputs in Assembler. It is stack intensive as C compilers of the 
day were, but deals with pointers efficiently. 4 level nested loops of 
structures don't belong in a retro C program is your first clue I think.

Switching registers a gazillion times is your second clue. This was always 
the case with other C's of the day too... including Microsoft C and Turbo C 
on the PC and 16 bit code. Those damned segments kepty getting reloaded and 
the only way to stop it was to generate an assembler pass then tweak it... 
for doing that in Aztec C, use the compiler option:

c65 -a -t main.c

This will produce an assembly listing with comments called main.a

This is the same code that Aztec C65 assembles using AS65 behind the scenes 
normally. The function calls offest the automatics (stack variables) and 
restore the stack when done. The register areas are on zero page (see 
zeropage.h in your include directory).

The most important thing here is to see how the 6502 registers get loaded, 
using primitive control structures in your program rather than higher level 
stuff.

And if I went running for an assembler every time I wrote an inefficient C 
program, I would never have been able to feed my family in the 80's and 90's 
is your third clue. So I stay away from assmbler until I have ruled-out my 
other options... including the use of a simple goto and linear arrays that 
require limited instructions to load offsets... this style is borrowed 
heavily from the sgemented architecture on the intel chips of the day... the 
motorola guys didn't need to worry about that so never really got the hang 
of it... linear memory makes one lazy. The 6502 for all intents and purposes 
follows the same methodology as a segmented approach, but on an 8 bit rather 
than 16 bit scale.

Anyone who can work in Qt can solve this... (and much more I should add) but 
I'll bet that running this algo on some old piece of big blue iron in PL1 or 
whatever some guy did back then wouldn't have run much better than what you 
put here, not meaning to be unkind, but just saying.

Stay away from the ML. That's a different culture. Download cc65 and compile 
this there too and do some of your own tests with that too. cc65 is an 
optimizing compiler, and not a retro-compiler. It doesn't make such use of 
the stack nor does it stay with integer data types like Aztec C65.

But from my experience with Aztec C, which is self-evident, your code should 
run at speeds that come close to cc65 on the Apple II. An understanding of 
the 6502 is a good thing too and using ML to speed-up an Aztec C or any C 
program requires intimate knowledge of the stack use of the Compiler and how 
registers are saved and restored, and the run-time environment of the link 
libraries etc.

Pseudo registers in Aztec C using pointers and using the inline assembly 
feature combined with assembly modules that are written with knowledge of 
the runtime are a good thing... cc65 doesn't provide inline assembly... 
that's a retro-compiler feathure.

To sum-up, take-out your biggest hammer and knock your structures apart, use 
pointers instead, with indexing on subscripts rather than incrementing the 
things. The assembler that this will generate is far better for porting to 
ml later. Goto's work well. Certainly that's all you will get with ML from 
most Apple II guys... using structured assmbly with vector dispatch tables 
and jump adresses  is unlikely from what I have seen so far... but that is 
just what I think.

Remember, your biggest hammer! The game is to beat the compiler... the year 
is  1986. If you write the thing well-enough your family will get groceries 
for the week... if you fail they will get peanut-butter sandwiches, not to 
mention the rent won't be paid!

Also, the professional reputation that you just got last week will be in the 
toilet and you'll need to go back to the drawing office, or finishing 
concrete again!

Anyway, if bllod-sport mentality doesn't get your adrenaline flowing, and it 
should pass that there is no enlightenment from your own private pain, never 
hesitate to email me what you can and it will not be tossed, just ignored 
for awhile. I should also refer you to the manuals on the website, but it is 
admittedly more fun to fly by the seat of ones pants when using something 
like this at the beginning. Remember this thing never really took-off on the 
Apple II. No C compiler did.

For very good reason, or many very good reasons. The biggest main one that I 
see from the top of the mountain is that given a local solution in assembly, 
few learned low-level C the way we did on the IBM-PC... the 6502 sucks too, 
but that makes it even more fun.

Give a man an 8086 or Z-80 C Compiler and what you will have is a man with a 
Compiler and no problems... but give a man a 6502 C compiler and Zero Page, 
and you'll get a man who will either run for BASIC and ML, or who will 
become a better C programmer.

Explore this stuff, and then let's get Qt up and start writing some 
cross-platform Apple II utilities with widgets and a proper UI. You've got 
the time I assume since you're doing your homework right now. You sure 
picked a hard way to go though:)

HNY

Bill

Thread

Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-01 21:40 +1300
  Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-01 09:15 -0800
    Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-02 08:18 +1300
      Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-01 14:44 -0600
        Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-02 21:38 +1300
          Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-02 04:49 -0600
            Re: Suggestions for improving speed of .SYS program. Steven Hirsch <snhirsch@gmail.com> - 2014-01-02 07:26 -0500
              Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-02 18:23 -0600
        Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-03 21:42 +1300
          Re: Suggestions for improving speed of .SYS program. David Schmidt <schmidtd@my-deja.com> - 2014-01-03 08:15 -0500
            Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-03 10:26 -0600
            Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-04 10:47 +1300
              Re: Suggestions for improving speed of .SYS program. Michael J. Mahon <mjmahon@aol.com> - 2014-01-04 04:11 -0600
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-05 12:53 +1300
            Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-03 23:55 -0800
              Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-05 13:58 +1300
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-04 20:24 -0800
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-06 11:11 +1300
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-08 20:43 +1300
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-08 15:41 -0800
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-09 21:34 +1300
                Re: Suggestions for improving speed of .SYS program. Michael J. Mahon <mjmahon@aol.com> - 2014-01-09 03:42 -0600
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-11 17:12 +1300
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-10 23:59 -0800
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-12 07:47 +1300
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-12 11:39 +1300
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-11 16:43 -0800
                Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-13 13:57 +1300
            Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-03 23:50 -0800
        Re: Suggestions for improving speed of .SYS program. ol.sc@web.de (Oliver Schmidt) - 2014-01-08 20:08 +0000
          Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-08 18:39 -0600
            Re: Suggestions for improving speed of .SYS program. Oliver Schmidt <ol.sc@web.de> - 2014-01-09 00:55 -0800
              Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-09 05:51 -0600
          Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-09 21:44 +1300
            Re: Suggestions for improving speed of .SYS program. Oliver Schmidt <ol.sc@web.de> - 2014-01-09 01:20 -0800
              Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-09 05:56 -0600
                Re: Suggestions for improving speed of .SYS program. David Schmidt <schmidtd@my-deja.com> - 2014-01-09 11:09 -0500
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-09 09:29 -0800
                Re: Suggestions for improving speed of .SYS program. David Schmidt <schmidtd@my-deja.com> - 2014-01-09 12:48 -0500
                Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-09 18:17 -0600
                Re: Suggestions for improving speed of .SYS program. aiiadict@gmail.com - 2014-01-09 20:57 -0800
                Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-10 05:41 -0600
                Re: Suggestions for improving speed of .SYS program. David Schmidt <schmidtd@my-deja.com> - 2014-01-10 07:56 -0500
                Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-10 19:49 -0600
                Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-10 08:39 -0800
                Re: Suggestions for improving speed of .SYS program. aiiadict@gmail.com - 2014-01-10 15:58 -0800
      Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-01 22:28 -0800
        Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-03 08:40 +1300
          Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-02 18:33 -0600
          Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-02 21:05 -0800
            Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-03 20:20 +1300
  Re: Suggestions for improving speed of .SYS program. "Anton Treuenfels" <teamtempest@yahoo.com> - 2014-01-02 18:58 -0600
    Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-03 21:05 +1300
      Re: Suggestions for improving speed of .SYS program. "Anton Treuenfels" <teamtempest@yahoo.com> - 2014-01-03 18:17 -0600
        Re: Suggestions for improving speed of .SYS program. "Bill Buckels" <bbuckels@mts.net> - 2014-01-03 21:32 -0600
        Re: Suggestions for improving speed of .SYS program. gids.rs@sasktel.net - 2014-01-03 23:15 -0800
          Re: Suggestions for improving speed of .SYS program. "Anton Treuenfels" <teamtempest@yahoo.com> - 2014-01-04 19:30 -0600
        Re: Suggestions for improving speed of .SYS program. Matt <matt@clickertraining.co.nz> - 2014-01-05 12:50 +1300

csiph-web