Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1022 > unrolled thread

Suggestions for improving speed of .SYS program.

Back to article view | Back to comp.sys.apple2.programmer

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1074

On 09/01/14 12:41, gids.rs@sasktel.net wrote:
> I also am a fan of compact efficient code.

Definitely. Looks like I spoke a bit too soon though. Breadth algo 
wasn't the breakthrough I was hoping for. Once again the performance 
gains I got using gcc just don't happen when I make the same changes to 
the aztec code. Frustratingly nothing I do seems to make any difference.

Turns out though that if you start with the hard coded first guess for 
breadth (index 8 0012) then just always play the first guess from the 
list of remaining possibilities you end up with a worst case of 8 
guesses to solve any secret and an average of 5.04 guesses. Using 
applewin at "authentic machine speed" this is easily fast enough for the 
game to be playable so that gives me some hope. Guess I kind of had a 
fixed line of thinking about using a published algorithm but why not do 
whatever works.

>  I wouldn't mind a copy of the finished system file when your done.

Absolutely.

Matt.

[toc] | [prev] | [next] | [standalone]

#1078

Matt <matt@clickertraining.co.nz> wrote:
> On 09/01/14 12:41, gids.rs@sasktel.net wrote:
>> I also am a fan of compact efficient code.
> 
> Definitely. Looks like I spoke a bit too soon though. Breadth algo wasn't
> the breakthrough I was hoping for. Once again the performance gains I got
> using gcc just don't happen when I make the same changes to the aztec
> code. Frustratingly nothing I do seems to make any difference.
> 
> Turns out though that if you start with the hard coded first guess for
> breadth (index 8 0012) then just always play the first guess from the
> list of remaining possibilities you end up with a worst case of 8 guesses
> to solve any secret and an average of 5.04 guesses. Using applewin at
> "authentic machine speed" this is easily fast enough for the game to be
> playable so that gives me some hope. Guess I kind of had a fixed line of
> thinking about using a published algorithm but why not do whatever works.
> 
>>  I wouldn't mind a copy of the finished system file when your done.
> 
> Absolutely.
> 
> Matt.

I really think it's time to do some profiling to see where the program
spends its time. 

Does the Apple you're running on have a source of interrupts?
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1106

On 09/01/14 22:42, Michael J. Mahon wrote:
> I really think it's time to do some profiling to see where the program
> spends its time.
>
> Does the Apple you're running on have a source of interrupts?

The apple I'm running on is the applewin emulator.

You might have seen earlier in the thread where I said I have no formal 
training in programming? For this reason please bear with me because 
there must already be 6-10 terms/concepts in the thread that I have only 
the sketchiest idea about. "profiling" and more so "source of 
interrupts" also are in that category.

I have what I think is a reasonable hunch where the program spends it's 
time namely in this function:

void get_score(int *secret, int *guess, int *score);

To illustrate here is some program output. The user has chosen 5,5,5,4 
for their secret code and now the computer solves it using the Knuth algo:

 >----<
guess 0011 0,0 256
guess 2234 1,0 18
guess 2545 1,2 3
guess 0044 1,0 1
guess 5554 4,0
5554 Knuth 5
 >----<

the guess 0011 receives the score 0,0 leaving 256 remaining possible 
answers. Now the computer must come up with it's next guess and this is 
what takes 10 - 20 minutes or more. Here's part of how it does it as 
best I can explain it:

For each pos_guess of 1296 possible guesses
   for each pos_scr of 14 scores pos_guess might receive
     for each rem_pos of 256 remining possible secrets
       if rem_pos were the actual secret what actual_score
       would pos_guess receive?
       if pos_scr != actual_score
         pos_guess would eliminate rem_pos as a rem_pos if it got
         pos_scr as a score

I've implemented the knuth algo quite a few times in working code but 
even so it's harder than you might think to lay it out clearly in 
pseudocode like that even supposing the indentation remains intact with 
different usenet clients etc.

Anyway If I've got things correct the '?' in my pseudocode above 
represents 1296 * 14 * 256 = 4,644,864 calls to get_score()

I just did this:
file scope:
int c2gs;//calls to get_score()
get_score(){
   if(nrem <= 256 && nrem > 18)//nrem: number of remaining possibilities
     c2gs++;
}
main(){
   c2gs = 0;
   solve(5554);
   print(c2gs);
}

and got 4,645,121 ??? anyway you get the picture it's a lot.

I started all this assuming that my code was the problem. After several 
days of making every possible improvement I'm starting to wonder if this 
is a computational task that requires the use of assembly language to 
work at reasonable speed on a stock //e. I could be completely wrong 
about this. Maybe I've implemented knuth in a really inefficient way 
resulting in way too many calls to get_score(). Like I said earlier in 
the thread it's driving me a bit mental but I can't seem to leave it alone.

Thanks Michael for your suggestions.

Matt.

[toc] | [prev] | [next] | [standalone]

#1108

> To illustrate here is some program output. The user has chosen 5,5,5,4 

> For each pos_guess of 1296 possible guesses
>    for each pos_scr of 14 scores pos_guess might receive
>      for each rem_pos of 256 remining possible secrets
>        if rem_pos were the actual secret what actual_score
>        would pos_guess receive?
>        if pos_scr != actual_score
>          pos_guess would eliminate rem_pos as a rem_pos if it got
>          pos_scr as a score



I don't know if I quite understand this language, but after the first guess you only have 256 guesses left.  You no longer need to compare them to the original 1296 possible guesses as the first best guess has already been made for you (0011) to substantially reduce the selection for the second best guess.  With the outcome that was returned to you of 0 RR and 0 RW, in this case this left you with 256 guesses for the second best guess.  The 1296 possible answers is only used initially to make an array of exclusions, or an array of answers that have not been excluded.  In your example, there are only 256 possible answers left after the first guess, where are you getting 4.6 million comparisons from.
After the second guess, there are only 18 possible guesses.

so calls to getscore would be like this:

first guess of 1296 possible answers = only 1296 calls to getscore
second guess of 256 possible answers = only 256 calls to getscore
third guess of 18 possible answers = only 18 calls to getscore

Not sure where the 4.6 million calls to get score are coming into play.

[toc] | [prev] | [next] | [standalone]

#1109

On 11/01/14 20:59, gids.rs@sasktel.net wrote:
> Not sure where the 4.6 million calls to get score are coming into play.

Yea I can kind of tell there's something wrong with how I've done it but 
I just can't put my finger on it yet without more study. With modern 
hardware I just write stuff so it does what I want it to then never look 
at it again. Everything happens in the blink of an eye anyway. I need to 
look at my knuth implementations from 2007 and 2011 to see if they also 
have this problem or it crept in in this new version.

[toc] | [prev] | [next] | [standalone]

#1110

On 11/01/14 20:59, gids.rs@sasktel.net wrote:
> The 1296 possible answers is only used initially to make an array of exclusions

Not 100% sure if you are correct there with respect.

One of the less obvious things about the knuth algorithm (it escaped me 
in 2007 when I first tried this) is that the set of "possible guesses" 
is the set "all possible guesses (length 1296)" not the set "guesses 
which actually could be the answer (length 256 , 18 ,whatever)" This is 
true at guess 1, guess 2 ... at every guess. Unless you have only 1 
remaining possibility you must find the max_min_elims 1296 times. That 
is how the algorithm works. Consistent mastermind in which you must make 
a guess which could be the answer is a whole different game. Knuth algo 
is concerned only with solving in fewest turns.

Looked at my 2011 code and no matter how I organise it I still end up 
with 4.5 million calls to get_score() to arrive at the second guess.

 From 
http://en.wikipedia.org/wiki/Mastermind_(board_game)#Five-guess_algorithm:

> Create a set S of remaining possibilities (at this point there are 1296).
<snip>
> For each possible guess (not necessarily in S)

"not necessarily in S" is the key.

Matt.

[toc] | [prev] | [next] | [standalone]

#1111

On Saturday, January 11, 2014 4:39:16 PM UTC-6, Matt wrote:
> On 11/01/14 20:59, gids.rs@sasktel.net wrote:
> > The 1296 possible answers is only used initially to make an array of exclusions

> Not 100% sure if you are correct there with respect.
>
> One of the less obvious things about the knuth algorithm (it escaped me 
> in 2007 when I first tried this) is that the set of "possible guesses" 
> is the set "all possible guesses (length 1296)" not the set "guesses 
> which actually could be the answer (length 256 , 18 ,whatever)" This is 
> true at guess 1, guess 2 ... at every guess. Unless you have only 1 
> remaining possibility you must find the max_min_elims 1296 times. That 
> is how the algorithm works. Consistent mastermind in which you must make 
> a guess which could be the answer is a whole different game. Knuth algo 
> is concerned only with solving in fewest turns.

> Looked at my 2011 code and no matter how I organise it I still end up 
> with 4.5 million calls to get_score() to arrive at the second guess.

>  From 
> 
> http://en.wikipedia.org/wiki/Mastermind_(board_game)#Five-guess_algorithm:

> > Create a set S of remaining possibilities (at this point there are 1296).
> <snip>
> > For each possible guess (not necessarily in S)

> "not necessarily in S" is the key.


That's what does not make sense to me.
since your first guess is 0011 and you get returned a 0 RR and a 0 RW, (right color right place and right color wrong place)

you no longer need to include any guess that has a 0 or a 1 in it.  This is why you only have 256 remaining guesses.  To use these two digits in any further calculations, especially with calculating the result is both redundant and time consuming.

of the 256 remaining guesses, there are only 6 second guesses that maximize the # of further reductions.  And those are 2233, 2244, 2255, 3344, 3355, and 4455

Obviously, this only works when you have a result of 0 and 0 when the guess is made up of only 2 numbers.

What disturbs me is, that the knuth algorithm still looks like it is comparing each guess with the actual answer just to calculate what the most likely next best guess should be.  That's cheating.  The computer is not supposed to know the answer.

So, here is another challenge to see if the program is working the way it should be.  Write the algorithm so that it needs input from a user for the result.  This way the computer never knows the answer and does not make any guesses using the real answer.

If the computer cannot resolve the answer, then it was cheating all along.

Rob

[toc] | [prev] | [next] | [standalone]

#1113

On 12/01/14 13:43, gids.rs@sasktel.net wrote:
> looks like it is comparing each guess with the actual answer just to calculate what the most likely next best guess should be

I don't think this is what is happening.

Think about how you do the eliminations after playing a guess. You take 
guess_just_made and score_received and go through 
remaining_possible_answers asking:

If this_one were the actual answer what_score would I have got for 
guess_just_made. If what_score != score_received delete this_one from
remaining_possible_answers.

This is exactly what knuth does except instead of guess_just_made and 
score_received you pass possible_next_guess and 
score_i_might_get_for_possible_next_guess. And you count the 
eliminations but don't actually make the deletions.

Each possible_next_guess has a set of 14 values for 
number_of_eliminations. Finding the least of these values involves 
making 14 * NUM_REMAINING_POSSIBILITIES calls to get_score(). And you 
must do this 1296 times.

I am confident that my knuth code arrives at it's next guess with 
reference only to known information which does not include the secret. 
Ie no cheating. If someone can conclusively demonstrate otherwise I will 
stand corrected. I do programming for a hobby and have never claimed to 
be any good at it. The code is here:

http://code.mattsmith.org.nz/mastermind/14no_struct_by_value.65/

As for replacing get_score() with myself I will never do this because it 
would be extremely tedious.

I have given up trying to implement knuth or kooi algos on apple2 such 
that they would run quickly enough for a usable game. One of two things 
is true:

1. It is not possible to do this in C.
2. Doing so is beyond my programming abilities at this time.

Either way I'm leaving it alone and moving on to write the actual 
program using whatever patched together way of getting the next guess 
will run fast enough for a decent user experience.

Matt.

[toc] | [prev] | [next] | [standalone]

#1047

> http://home.comcast.net/~mjmahon/Sudoku.html

> What was the right language for this?  They ended up using quite a few 
> of the 6502's characteristics that probably would have been awkward in a 
> higher-level language; or at least it would require a way to shake free 
> of a compiler and simply say "pass this to the assembler instead..."


They used the one thing that tremendously speeds up the execution time.  And that is tables of every possible answer.

Any language can use tables, basic, pascal, cc65, any compiler.  This greatly reduces the number of calculations to achieve the answer, when every possible answer can be compared to the current situation until one answer fits.

This is how master mind is being compared as well.  The initial guess is already a given (usually 0011) and a comparison of the guess to all 1296 possible answers is done to compare with the score that was potentially fed back to the computer.  The computer is just set up to calculate the score for itself instead of having a user input it in for it.

The most calculated loop is the one where the guess is compared to each of the 1296 possible answers to get the score that should have been fed into the computer.  A table with a score to all the comparisons would have to be pre-generated for fast look up.

[toc] | [prev] | [next] | [standalone]

#1071

Hi Bill,

>[...] 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. [...]

Thanks for adding this friendly hint regarding cc65 :-)

>[...] cc65 doesn't provide inline assembly... [...]

Actually it does: http://oliverschmidt.github.io/cc65/doc/cc65.html#s9

Maybe you remember the thread "Introduction to to Graphics in C on the
Apple II" from 2010 in this group. There I converted "for you" an
Aztec C program with inline assembly converted to cc65...

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#1073

"Oliver Schmidt" <ol.sc@web.de> wrote:
>Hi Bill

Hi Oliver.

>Actually it does: http://oliverschmidt.github.io/cc65/doc/cc65.html#s9

Actually it does not.

Aztec C as you are aware uses the #asm compiler directive which allows the 
insertion of complete functions written in assembly.

Quite frankly, what cc65 offers is puny, awkward to code in my opinion, and 
not what I would call inline assembly.  It is, properly put. a "CLUDGE".

You can't put lipstick on a fish and call it a woman.

Bill

[toc] | [prev] | [next] | [standalone]

#1076

Hi Bill,

> >Actually it does: http://oliverschmidt.github.io/cc65/doc/cc65.html#s9
>
> Actually it does not.
>
>
> 
> Aztec C as you are aware uses the #asm compiler directive which allows the 
> 
> insertion of complete functions written in assembly.
> 
> 
> 
> Quite frankly, what cc65 offers is puny, awkward to code in my opinion, and 
> 
> not what I would call inline assembly.  It is, properly put. a "CLUDGE".
> 
> 
> 
> You can't put lipstick on a fish and call it a woman.

And I was stupid enough to think that after all these years you had finally passed the point of those stupid discussions :-(

Anyway - so here we go again...

If you just re-define a well-known term at will then you can of course derive any statement - but of course that statement is then useless.

Some references regarding the term 'inline assembly':
http://en.wikipedia.org/wiki/Inline_assembler
http://wiki.osdev.org/Inline_Assembly
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

So inline assembly is _explicitly_ not about "inserting complete functions". That's what a "full" assembler is for - and cc65 comes with such a full assembler and therefore doesn't require kludge like putting complete assembly functions in C code.

Rather inline assembly is about efficient access to C data like formal parameters and local variables (see references above). The cc65 inline assembler allows this access - as I showed you in the 2010 thread mentioned above. In contrast your Aztec C "inline assembly" code required the _real_ kludge of C code that puts formal parameters in global variables just for the "inline assembly" to pick them up.

Just straighten out things,
Oliver

[toc] | [prev] | [next] | [standalone]

#1079

"Oliver Schmidt" <ol.sc@web.de> wrote:
Bill Buckels wrote:
>> You can't put lipstick on a fish and call it a woman.
>And I was stupid enough to think that after all these years you had finally 
>passed the point of those stupid discussions :-(

Hi Oliver,

Well, I can see that you are as intolerant as I am.

That's just my opinion Oliver after 30 years of using inline assembly with C 
extensively in several compilers on several platforms. But to you and those 
who like modern compilers, Aztec C is the fish, and opinions that conflict 
with your own are as stupid as my own, no-more and no-less.

And I read Wikipedia's article on inline assembly before giving you my 
opinion which you FEEL is stupid. The article is a stub. I will need to add 
to the inline assembly article to provide more detail and a historical 
perspective as to how inline assembly has devolved to its present 
watered-down lame version.

Quoting some links seems stupid to me since opinions are like brains; 
everybody has one. As a Wikipedia Author, I have cleaned-up articles before, 
like the unilateral cross-compiler article that was orginally provided with 
a limited perspective.

Aztec C's inline assembly is full-featured without you trying to redefine 
what a compiler or an assembler is and isn't, especially when the compilers 
and assemblers that use a different approach to cc65 have been around for 30 
years. Aztec C and Microsoft C and Borland C use variants of the asm block 
to insert pure instructions. cc65 uses a lame approach.

If I was going to compare cc65's inline assembly I would compare it to 
Microsoft BASIC on the IBM-PC.

See my wikipedia article on the BSAVE image format for an example of that.

Just straighten-out things yourself. Totalitarianism cannot change history.

Sorry if my opinions hurt your feelings, or conflict with your opinions on 
the use of usenet. cc65 is a modern compiler and produces quicker, smaller, 
and more efficient code than Aztec C. Aztec C has features that I like, and 
is easier for me and others like me to use.

Whether there are others like me left on this planet is also a matter of 
opinion.

Bill

[toc] | [prev] | [next] | [standalone]

#1075

On 09/01/14 09:08, Oliver Schmidt wrote:
> Thanks for adding this friendly hint regarding cc65:-)

I'm glad you chimed in here Oliver. For some unknown reason 
(possibility: I'm an idiot) I thought Bill was talking about the 
compiler that comes with the aztec prodos shell which of course made no 
difference speed-wise for my code. I just looked at the website and I'll 
absolutely be giving cc65 a go. Inline assembly or lack thereof (I'm 
staying out of that discussion:-)) is moot for me at this point because 
I wouldn't know how to use it anyway.

Matt.

[toc] | [prev] | [next] | [standalone]

#1077

Hi Matt,

> I just looked at the website and I'll 
> absolutely be giving cc65 a go.

Please make sure to go for http://oliverschmidt.github.io/cc65/ (in contrast to http://www.cc65.org/) for the latest code.

However don't expect too much speedup as cc65 doesn't come with a full blown optimizer. Such optimizers do i.e. things like CSE (http://en.wikipedia.org/wiki/Common_subexpression_elimination). As a result it just doesn't matter if you use pointers or array indexes to access data sets because the optimizer will usually generate the same code for both variants anyway. The cc65 optimizer is far from such capabilities.

Anyway (with the exception of missing floating point support) cc65 allows most of the times to compile exsisting, "usual" C code without changes. This should come in handy for your scenario.

> Inline assembly or lack thereof (I'm 
> staying out of that discussion:-)) [...]

Wise decision ;-)

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#1080

"Oliver Schmidt" <ol.sc@web.de> wrote:
>Wise decision ;-)

I suppose. But you still can't put lipstick on a fish.

Bill 

[toc] | [prev] | [next] | [standalone]

#1081

On 1/9/2014 6:56 AM, Bill Buckels wrote:
> "Oliver Schmidt" <ol.sc@web.de> wrote:
>> Wise decision ;-)
>
> I suppose. But you still can't put lipstick on a fish.

To paraphrase the old joke... you could, but it wastes your time and 
annoys the fish.

[toc] | [prev] | [next] | [standalone]

#1082

> > I suppose. But you still can't put lipstick on a fish.
 
> To paraphrase the old joke... you could, but it wastes your time and 
> annoys the fish.


It's not really a waste of time if it creates a conversation piece, and how can you tell the fish is annoyed when it looks like it is always smiling?

[toc] | [prev] | [next] | [standalone]

#1084

On 1/9/2014 12:29 PM, gids.rs@sasktel.net wrote:
>
>>> I suppose. But you still can't put lipstick on a fish.
>
>> To paraphrase the old joke... you could, but it wastes your time and
>> annoys the fish.
>
> It's not really a waste of time if it creates a conversation piece, and how can you tell the fish is annoyed when it looks like it is always smiling?

I think fish always look annoyed.

[toc] | [prev] | [next] | [standalone]

#1092

"David Schmidt" <schmidtd@my-deja.com> wrote:
>I think fish always look annoyed.

There are strange things done in the midnight sun
      By the men who moil for code;
The Arctic trails have their secret tales
      That would make your blood run cold;
The Northern Lights have seen queer sights,
      But the queerest they ever did see
Was that fishy string with the lipstick thing
     that impersonated inline assemblee...

I think the other really annoying thing about fish wearing lipstick, is that 
unless one is experienced enough to know the difference from the real thing, 
they can end-up marrying the fish instead of eating it.

Stay away from fish wearing lipstick whether they look annoyed or are 
smiling is the best advice I can give.

Bill 

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web