Effective February 22, 2024, Google Groups will no longer support new Usenet content. Posting and subscribing will be disallowed, and new content from Usenet peers will not appear. Viewing and searching of historical data will still be supported as it is done today.
Dismiss

K&R C?

28 views
Skip to first unread message

Harry Potter

unread,
Jul 20, 2009, 11:23:17 AM7/20/09
to
What's the difference between K&R C and ANSI/ISO C?
-----------
Joseph Rose, a.k.a. Harry Potter
Working magic in the computer community...or at least trying to! :(

Dombo

unread,
Jul 20, 2009, 1:22:31 PM7/20/09
to
Harry Potter schreef:

> What's the difference between K&R C and ANSI/ISO C?

http://en.lmgtfy.com/?q=What%27s+the+difference+between+K%26R+C+and+ANSI%2FISO+C

Lars Haugseth

unread,
Jul 20, 2009, 2:28:34 PM7/20/09
to

rotflmao.

--
Lars Haugseth

Harry Potter

unread,
Jul 21, 2009, 12:36:24 PM7/21/09
to
On Jul 20, 10:22 am, Dombo <do...@disposable.invalid> wrote:
> Harry Potter schreef:
>
> > What's the difference between K&R C and ANSI/ISO C?
>
> http://en.lmgtfy.com/?q=What%27s+the+difference+between+K%26R+C+and+A...

What about the library? Which ANSI C functions are unavailable, and
which are different? BTW, I want to use cc64 and Power C and,
perhaps, Turbo C.

lyricalnanoha

unread,
Jul 21, 2009, 12:45:59 PM7/21/09
to

On Tue, 21 Jul 2009, Harry Potter wrote:

CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
K&R.

I haven't had a need to use K&R for anything.

-uso.

Martijn van Buul

unread,
Jul 22, 2009, 4:09:10 AM7/22/09
to
* lyricalnanoha:

> I haven't had a need to use K&R for anything.

In fact, I would try to avoid using K&R at all cost.

--
Martijn van Buul - pi...@dohd.org

Lars Haugseth

unread,
Jul 22, 2009, 4:39:51 AM7/22/09
to
* Martijn van Buul <pi...@dohd.org> wrote:
>
> * lyricalnanoha:
>> I haven't had a need to use K&R for anything.
>
> In fact, I would try to avoid using K&R at all cost.

The second edition of Kernighan & Ritchie's "The C Programming Language"
has been updated to use ANSI C. That in itself should be a pretty strong
indication that K&R C is best left behind.

--
Lars Haugseth

Harry Potter

unread,
Jul 22, 2009, 12:37:55 PM7/22/09
to
On Jul 21, 9:45 am, lyricalnanoha

<lyricalnan...@usotsuki.hoshinet.org> wrote:
> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
> K&R.
>
I said cc64, NOT cc65. As for Turbo C, I am talking about the one
that uses $i instead of #include and is made by one with little
knowledge of English, in case we're talking about two different Turbo
C's.

> I haven't had a need to use K&R for anything.
>

Will ANSI C work hosted on a C64/128? I plan to create one.

commodorejohn

unread,
Jul 22, 2009, 1:40:43 PM7/22/09
to
On Jul 22, 11:37 am, Harry Potter <maspethro...@aol.com> wrote:
> I said cc64, NOT cc65.
Looking at CC64's documentation, it says it's "a small C compiler,"
which usually means it's for the Small-C subset of the C language
(http://en.wikipedia.org/wiki/Small_C) This is *not* ANSI, as it's
missing various features (i.e. floating-point.)

> Will ANSI C work hosted on a C64/128? I plan to create one.

Not sure what the question is here. Are you asking whether ANSI C can
be used on a Commodore? Obviously the answer is yes, as CC65 is ANSI.
Or are you talking about creating an ANSI C compiler that runs on a
Commodore?

Bill Buckels

unread,
Jul 22, 2009, 6:58:34 PM7/22/09
to

"Martijn van Buul" <pi...@dohd.org> wrote:
>In fact, I would try to avoid using K&R at all cost.

Not me.

Aztec C for the C64 is a great cross-compiler as anyone who knows anything
at all about writing C programs in Windows that run on the C64 knows and it
is of course K&R.

http://www.aztecmuseum.ca/

http://www.c64classics.ca/

Bill Buckels

unread,
Jul 22, 2009, 7:20:03 PM7/22/09
to

"Lars Haugseth" <nj...@larshaugseth.com> wrote:
>That in itself should be a pretty strong indication that K&R C is best left
>behind.

Others might say that C itself is best left behind and we should write in
D.

What does the Commodore 64 indicate? K&R is vintage C just as the Commodore
64 is a vintage computer. The two work perfectly together.

I had great fun putting together the SID and Graphics routines for the Aztec
C64 cross-compiler. It works fine in Ubuntu under DOSEmu and in DOSBox as
well as in Windows Xp or Vista which is a pretty strong indication that it
is still useful on a variety of hosts albeit best used by those who
appreciate vintage tools and not some undeserving newbie.

On that point I am inclined to agree.

http://www.clipshop.ca/Aztec/compilers.htm#commodore

Other features of this K&R compiler are the use of overlays which is
something else that I like about the Aztec C64 compiler.

http://www.clipshop.ca/Aztec/docs/time64.txt

sampsa

unread,
Jul 23, 2009, 1:39:52 PM7/23/09
to
On Jul 20, 7:28 pm, Lars Haugseth <n...@larshaugseth.com> wrote:
> * Dombo <do...@disposable.invalid> wrote:
>
> > Harry Potter schreef:
> >> What's the difference between K&R C and ANSI/ISO C?
>
> >http://en.lmgtfy.com/?q=What%27s+the+difference+between+K%26R+C+and+A...
>
> rotflmao.
>
> --
> Lars Haugseth

This guy is such a tool. Joe/Harry, you are either one of the dumbest
posters or smartest trolls I've ever seen - which is it?


commodorejohn

unread,
Jul 23, 2009, 2:32:18 PM7/23/09
to
On Jul 22, 6:20 pm, "Bill Buckels" <bbuck...@mts.net> wrote:
> Others might say that C itself is best left behind and we should write in
> D.
>
> What does the Commodore 64 indicate? K&R is vintage C just as the Commodore
> 64 is a vintage computer. The two work perfectly together.
Well, the guiding principle is of course to use whatever language
works best for you. Still, there are some fair criticisms of K&R C,
and it's missing some ANSI C features (void functions, struct
assignment, etc.) that really can make programming easier and less
error-prone.

Joel Koltner

unread,
Jul 23, 2009, 6:37:51 PM7/23/09
to
"commodorejohn" <commod...@gmail.com> wrote in message
news:08df1290-537b-4aa9...@32g2000yqj.googlegroups.com...

> Still, there are some fair criticisms of K&R C,
> and it's missing some ANSI C features (void functions, struct
> assignment, etc.) that really can make programming easier and less
> error-prone.

20 years from now you'll be able to say the same thing about languages we're
using today. :-)

The field of "computer science" didn't really exist when Kernigan and Ritchie
were crafting the original C spec...


Bill Buckels

unread,
Jul 23, 2009, 6:45:37 PM7/23/09
to

"commodorejohn" <commod...@gmail.com> wrote:
>Still, there are some fair criticisms of K&R C

And also some fair criticisms of the Commodore 64 but not by me.

>and it's missing some ANSI C features (void functions, struct assignment,
>etc.) that really can make programming easier and less error-prone.

The Commodore 64 is missing features such as ROM and an Operating System
that really can make programming easier as well. The Apple //e has both
these, but certain people like me don't need or want all that new-fangled
complexity all the time.

My programming is hardly error prone either whether I use K&R or ANSI or ISO
C or whether I program for the C64,

http://www.c64classics.ca
http://www.c64classics.ca/index.htm#gdemo
http://www.c64classics.ca/index.htm#sdemo

Apple //e, or

http://www.appleoldies.ca/

IBM-PC or

http://www.clipshop.ca/
http://www.teacherschoice.ca/

CP/M 80, Mac, Linux or whatever.

http://www.cpm8680.com/

Others will shoot themselves in the foot even in Ladybug Logo or BASIC or
whatever and others won't.

Trolls who do nothing won't but we can always hope.

All I can say in addition to all this is that Aztec C Rules!, K&R or not...

http://www.aztecmuseum.ca/compilers.htm#commodore


Brandon Staggs

unread,
Jul 23, 2009, 7:24:50 PM7/23/09
to

Regardless of the standard, K&R's "The C Programming Language" is
probably the best (technical) programming book I've read. I have the
updated edition that has the ANSI stuff.

And I don't even program in C unless I really have to.

--
-Brandon
http://www.brandonstaggs.com/c64.html

commodorejohn

unread,
Jul 23, 2009, 7:31:12 PM7/23/09
to
On Jul 23, 5:37 pm, "Joel Koltner" <zapwireDASHgro...@yahoo.com>
wrote:

> The field of "computer science" didn't really exist when Kernigan and Ritchie
> were crafting the original C spec...
Please understand: I'm not faulting K&R C for not making all the
advancements at once. The changes from K&R to ANSI C were born out of
years of trial and error by many different users of the language, and
it would be silly to degrade something for not being its own
successor. K&R C is still a good language, and light-years better than
some other languages available on the Commodore (precisely WHY did
they do a COBOL implementation, again?) I'm just saying that, other
concerns aside (which is a fairly large caveat, considering how
library availability and customization to the target machine can
factor into the equation, and of course the all-important personal
preference,) ANSI C is generally a better language. All due respect to
K&R C for being there first, but ANSI C is still better *when
evaluating it solely as a language.*

lyricalnanoha

unread,
Jul 23, 2009, 9:49:05 PM7/23/09
to
On Thu, 23 Jul 2009, Bill Buckels wrote:

> The Commodore 64 is missing features such as ROM and an Operating System
> that really can make programming easier as well. The Apple //e has both
> these, but certain people like me don't need or want all that new-fangled
> complexity all the time.

Yeah, sometimes when trying to port stuff the lack of commands like
CLS/HOME, VTAB/HTAB/LOCATE, or even graphics functionality just has me
headwalling :/

I've even thought about whether porting FPBASIC itself to the 64 might be
of use for some stuff I want to do, n/m that C64 BASIC is almost FPBASIC
already.

-uso.

Martijn van Buul

unread,
Jul 24, 2009, 3:27:38 AM7/24/09
to
* Bill Buckels:

>
> "Martijn van Buul" <pi...@dohd.org> wrote:
>>In fact, I would try to avoid using K&R at all cost.
>
> Not me.
>
> Aztec C for the C64 is a great cross-compiler as anyone who knows anything
> at all about writing C programs in Windows that run on the C64 knows and it
> is of course K&R.

CC65 is a great cross compiler, can be legally had, is open source, and has
been developed by a number of people who used to frequent this very newsgroup..

And, it is of course ANSI :)

Groepaz

unread,
Jul 25, 2009, 5:57:55 AM7/25/09
to
lyricalnanoha wrote:


> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
> K&R.

cc65 can handle k&r too (afaik that is a requirement for an ansi-c compiler)

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Eine Diskussion ist unmï¿œglich mit jemandem, der vorgibt, die Wahrheit nicht
zu suchen, sondern schon zu besitzen.
<Romain Rolland>


Groepaz

unread,
Jul 25, 2009, 6:01:29 AM7/25/09
to
Martijn van Buul wrote:

indeed. aztec-c is pretty poo compared to it =P

--

It doesn't matter who votes. What matters is who counts the votes.
<Josef Stalin>


Groepaz

unread,
Jul 25, 2009, 6:02:21 AM7/25/09
to
Harry Potter wrote:

> On Jul 21, 9:45ï¿œam, lyricalnanoha


> <lyricalnan...@usotsuki.hoshinet.org> wrote:
>> CC65 and Turbo C are both ANSI, at any rate, although Turbo C can handle
>> K&R.
>>
> I said cc64, NOT cc65.

link to it please

> As for Turbo C, I am talking about the one
> that uses $i instead of #include and is made by one with little
> knowledge of English, in case we're talking about two different Turbo
> C's.

link to it please

>> I haven't had a need to use K&R for anything.
>>
> Will ANSI C work hosted on a C64/128? I plan to create one.

link to it please

--

Aesthetic delight lies somewhere between boredom and confusion.
<E.H.Gombrick>


Groepaz

unread,
Jul 25, 2009, 6:03:36 AM7/25/09
to
commodorejohn wrote:

> On Jul 22, 11:37 am, Harry Potter <maspethro...@aol.com> wrote:
>> I said cc64, NOT cc65.
> Looking at CC64's documentation, it says it's "a small C compiler,"
> which usually means it's for the Small-C subset of the C language
> (http://en.wikipedia.org/wiki/Small_C) This is *not* ANSI, as it's
> missing various features (i.e. floating-point.)

cc65 is a small-c based compiler too :) (and it also doesnt have floating
point - which you dont need anyway and should avoid at any cost on a
8bit/1mhz machine)

--

Ich ziehe meinen Hut vor den Hackern. Die zeigen denen, die fï¿œr ihre
angeblich todsicheren Codes Millionen und Milliarden investiert haben, dass
sie fï¿œr das Knacken von Codes nur eine halbe Stunde gebraucht haben.
<Rod Gonzalez>


Spiro Trikaliotis

unread,
Jul 25, 2009, 1:16:09 PM7/25/09
to
Hello Gpz,

Groepaz wrote:

> cc65 can handle k&r too (afaik that is a requirement for an ansi-c compiler)

No, it is optional only for a C89/C90 compiler.

Regards,
Spiro.

--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

Bill Buckels

unread,
Jul 25, 2009, 3:00:03 PM7/25/09
to

"Groepaz" <gro...@gmx.net> wrote:

>cc65 is a small-c based compiler too :) (and it also doesnt have floating
>point - which you dont need anyway and should avoid at any cost on a
>8bit/1mhz machine)

Aztec C is a better compiler since smarter people wrote it, it is legally
available by permission of its copyright holder, uses overlays, is K&R and
has floating point which in fact is very handy for writing programs like the
following and works fine on 8bit machines which is what made Aztec the
largest selling 8 bit C compiler in the 1980's .

http://www.aztecmuseum.ca/compilers.htm#commodore

http://www.aztecmuseum.ca/time64.zip

CC65 is poo by comparison regardless of who frequented this ng at one time.
What have they done lately? Until they do what I have done in Aztec C and
other C's I doubt if their opinions can be taken seriously.


Bill Buckels

unread,
Jul 25, 2009, 8:02:15 PM7/25/09
to

"lyricalnanoha" <lyrica...@usotsuki.hoshinet.org> wrote:
>I haven't had a need to use K&R for anything.

That's because you haven't tried any of my Aztec C distributions yet uso...
if you did then you might have a need to use K&R and Aztec C for
everything:)

Aztec C Apple II DOS 3.3 and ProDOS 8, C64, and CP/M 80 compilers might be
worth a try...


lyricalnanoha

unread,
Jul 25, 2009, 10:25:58 PM7/25/09
to

In the 6502 realm CC65/CA65 has served my purposes fine. In the Z80
realm, Hitech had an ANSI compiler which is still out and about (and I
think it's still commonly used in MSX circles).

I honestly don't see what advantage Aztec could have other than in library
support, and even that isn't impossible to replicate.

-uso.

commodorejohn

unread,
Jul 26, 2009, 12:09:18 AM7/26/09
to
On Jul 25, 9:25 pm, lyricalnanoha

<lyricalnan...@usotsuki.hoshinet.org> wrote:
> In the 6502 realm CC65/CA65 has served my purposes fine. In the Z80
> realm, Hitech had an ANSI compiler which is still out and about (and I
> think it's still commonly used in MSX circles).
Don't forget SDCC for the Z80, which is specifically targeted towards
low-end systems (although MSX and CP/M support are rather limited
right now.)

> I honestly don't see what advantage Aztec could have other than in library
> support, and even that isn't impossible to replicate.

Eh, if Aztec C has a better code generator than CC65, that could make
a real difference on such low-end hardware. However, I don't really
know if that's the case, and even so, some programmers (myself
included) might feel that the features added in ANSI C make up for any
slight deficiencies in other areas.

Honestly, Mr. Buckels seems to just be offended that people might
prefer another product to his compiler of choice, which, in the
absence of hard comparisons to back it up, is pretty silly.

Groepaz

unread,
Jul 26, 2009, 5:05:43 AM7/26/09
to
Bill Buckels wrote:

really: LOL

you know, there is a reason for you beeing the only aztec-c user. and there
is a reason for the only time anyone ever hears about this compiler, it's
your constant ramblings about it here.

also: LOL

--

Der Zyniker sieht die Welt wie sie ist, nicht wie sie sein sollte.


Groepaz

unread,
Jul 26, 2009, 5:06:47 AM7/26/09
to
Spiro Trikaliotis wrote:

> Hello Gpz,
>
> Groepaz wrote:
>
>> cc65 can handle k&r too (afaik that is a requirement for an ansi-c
>> compiler)
>
> No, it is optional only for a C89/C90 compiler.

ok =) i don't think i have ever stumbled about a compiler that does ansi-c
and NOT k&r :) or mmmh.... maybe sdcc? dont recall =)

--

...nuclear war could alleviate some of the factors leading to today's
ecological disturbances that are due to current high population
concentrations and heavy industrial production.
<US Office of Civil Defense>


Groepaz

unread,
Jul 26, 2009, 5:14:47 AM7/26/09
to
commodorejohn wrote:

> Eh, if Aztec C has a better code generator than CC65, that could make
> a real difference on such low-end hardware. However, I don't really
> know if that's the case,

the differences are, lets say.... not worth talking about. infact when i
tested a few compilers some years ago, "power-c" produced the
most "optimal" (from an assembler programmer point of view) code - but at
the same time power-c is kinda limited in features (k&r, preprocessor is
crap etc). aztec-c and cc65 produce similar code quality, with cc65 beeing
MUCH more bugfree, especially in border situations. cc65 is also the only
available 6502 compiler that even vaguely follows some standards.

if you want some hints on how bad a certain compiler fails, you can try
http://hitmen.c02.at/files/cc65/testsuite_test3.tar.gz (many tests are also
available in k&r even)

[some day i should finally clean up and commit my floating point library so
those who think they really need them can stop whining too =P]

--

It is not possible to simultaneously understand and appreciate the Intel
architecture.
<Ben Scott>


Bill Buckels

unread,
Jul 26, 2009, 5:44:07 AM7/26/09
to

"commodorejohn" <commod...@gmail.com> wrote:

>lyricalnanoha wrote:

>> library support

That's one area and overlay and floating point support are two other areas.
Inline assembly is a third area. But you are right. It is worth downloading
my Aztec C distributions just to play with the samples and library source.

>>that isn't impossible to replicate

Why reinvent the wheel?

http://aztecmuseum.ca/ads/nibble-jul-84-aztec.pdf

>Mr. Buckels seems to just be offended that people might prefer another
>product to his compiler of choice

No because these people don't really prefer anything. Most just don't know
my Aztec C distributions because they've never tried them and therefore
don't know anything. Yet.

And I am not really offended. What I think is silly is to preclude trying a
good compiler because it is old and not ANSI. ANSI support is a very silly
reason to condemn a compiler or rather to solely use to chose one compiler
over another. Very very silly. Tsk tsk tsk.

http://aztecmuseum.ca/ads/index.htm

>which, in the absence of hard comparisons to back it up, is pretty silly.

The comparisons for Aztec C are a matter of history and it was always really
good but some of these others like the people who use them haven't the same
history but performance is not the only criteria. If it is important here's
a link:

http://www.textfiles.com/programming/dstone.c

But especially try this link:

http://en.lmgtfy.com/?q=drhystone+compiler+Aztec+C+apple+performance

What is also pretty silly is that a bunch of people who haven't used Aztec C
share a silly opinion on it. These are people who may not have ever used an
overlay or done some of the other silly fun stuff that doesn't care whether
a compiler is ANSI or not:

http://www.aztecmuseum.ca/projects.htm#dos33

http://www.aztecmuseum.ca/projects.htm#prodos

http://www.aztecmuseum.ca/projects.htm#c64

So forgive me for being silly and I'll forgive you back.

One thing for sure... if nobody is going to use the Aztec C distributions
that I have put together, nobody is surely going to use anything that Joseph
Rose puts together.

- The Aztec C Evangelist:)



Bill Buckels

unread,
Jul 26, 2009, 6:16:41 AM7/26/09
to

"Groepaz" <gro...@gmx.net> wrote:

>you know, there is a reason for you beeing the only aztec-c user.

There were actually more than one Aztec C users. Aztec C outsold all other C
compilers in the mid-1980's but newbies like you can be forgiven for not
knowing your history.

http://en.wikipedia.org/wiki/Aztec_C

The reason is that I was doing cross-development for the C64 on my IBM-PC
about 30 years ago and actually paid for a licence which cost more than
several Commodore 64's. At that time the average C64 user wasn't buying much
and also not so many did cross-development work on the IBM-PC and many could
not even afford an IBM-PC.

http://en.wikipedia.org/wiki/Cross-compiler#Manx_Aztec_C_cross_compilers

Plain and simple... it was so expensive and specialized that despite the
fact that it was good only serious professional cross-platform developers
used it.

Today with the C64 and other 6502 and Z80 development now being done on
cross-compilers the Aztec C cross-compiler is accesible to others who could
not have ever afforded it when I purchased it.

>and there is a reason for the only time anyone ever hears about this
>compiler, it's your constant ramblings about it here.

That might be true if the "anyone" that you are talking about is within this
ng or a hitman or something. Also LOL.

And that is also the reason your opinion is worthless on this compiler.

Groepaz

unread,
Jul 26, 2009, 6:42:47 AM7/26/09
to
Bill Buckels wrote:

> There were actually more than one Aztec C users.

yes. *were*. what about now?

> Aztec C outsold all other
> C compilers in the mid-1980's but newbies like you can be forgiven for not
> knowing your history.

LOL again. back in the days i quickly went from basic compilers (yuck!),
over pascal compilers (slightly better), several c-compilers (acceptable
but still suboptimal) to plain assembler. simply because there is only very
limited use for compilers on 8bit targets for games and demos and alike.
(and ofcourse it is still like that)

> The reason is that I was doing cross-development for the C64 on my IBM-PC
> about 30 years ago and actually paid for a licence which cost more than
> several Commodore 64's. At that time the average C64 user wasn't buying
> much and also not so many did cross-development work on the IBM-PC and
> many could not even afford an IBM-PC.

you'd be surprised how common cross development was even back then. but
indeed, mostly it was about assembler, not compilers. does datels PDS tell
you anything?

> Plain and simple... it was so expensive and specialized that despite the
> fact that it was good only serious professional cross-platform developers
> used it.

bullshit, price means nothing. (and all compilers were crazy expensive,
except the most terrible ones) you can also always get the helluva
expensive "professional" 6502 and 65816 compiler from wdc - guess why
people still prefer cc65 though, even the sunplus guys =P

so did you ever compare the generated code to that of cc65? (i wish i would
have kept the output of the tests)

> That might be true if the "anyone" that you are talking about is within
> this ng or a hitman or something. Also LOL.

so you surely have some links to recent non trivial projects done with it?
something like for example zoomania
(http://noname.c64.org/csdb/release/?id=74653) or contiki
(http://www.sics.se/contiki/)

(links to actual binaries for a c64 please)

--

I am pretty sure that whenever you make the statement "I am right and the
entire industry is wrong." you are, in fact, the one who is wrong. Unless
your name happens to be Steve Wozniak, and it happens to be 1976.


Bill Buckels

unread,
Jul 26, 2009, 6:49:39 AM7/26/09
to

"Groepaz" <gro...@gmx.net> wrote:

>aztec-c and cc65 produce similar code quality

I wonder why I should believe this statement because you also wrote:

>you know, there is a reason for you beeing the only aztec-c user. and there

>is a reason for the only time anyone ever hears about this compiler, it's
>your constant ramblings about it here.

I think the more constant of the ramblings may be the ramblings about CC65
and nothing much that wasn't already done a long time before. This whining
of bugs in Aztec C seems to be arguable based on my experience... my Aztec C
code for the C64 seems to work pretty well.

>[some day i should finally clean up and commit my floating point library so
>those who think they really need them can stop whining too =P]

Why reinvent the wheel? Aztec C does floating point and has for 30 years.

Of course I do agree that floating point should also be used optimally as in
the Aztec C code below which is used to draw the hands on a clock in one of
my Aztec C programs for the C64 and the Apple II:

(just use floats where required and use integers to store results - only a
fool would do otherwise on an 8bit machine:)

circlepoints(x,y,baselength,fdegrees)
int *x, *y;
int baselength;
float fdegrees;
{
float xtemp;
float ytemp;
int degrees = (int )fdegrees;
float aspect_h, aspect_v;

aspect_h = (float)1.16;
aspect_v = (float)1;

/* starting at 12 O'clock */
/* use a switch for the break */
switch(degrees)
{


default:

/* within range */
if(degrees<0 || degrees >359)degrees=0;

/* 0-45 sin */
if(degrees < 45)
{
xtemp = (float) sine_cosine[degrees][0];
ytemp = (float) sine_cosine[degrees][1];
ytemp = ytemp * -1;
break;
}

/* 45-90 cos */
if(degrees < 90)
{
xtemp = (float) sine_cosine[90-degrees][1];
ytemp = (float) sine_cosine[90-degrees][0];
ytemp = ytemp * -1;
break;
}

/* 90 - 135 */
if(degrees < 135)
{
xtemp = (float) sine_cosine[degrees-90][1];
ytemp = (float) sine_cosine[degrees-90][0];
break;
}

/* 135 - 180 */
if(degrees< 180)
{
xtemp = (float) sine_cosine[180-degrees][0];
ytemp = (float) sine_cosine[180-degrees][1];
break;
}

/* 180 - 225 */
if(degrees< 225)
{
xtemp = (float) sine_cosine[degrees-180][0];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[degrees-180][1];
break;
}

/* 225 - 270 */
if(degrees< 270)
{
xtemp = (float) sine_cosine[270-degrees][1];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[270-degrees][0];
break;
}

/* 270 - 315 */
if(degrees< 315)
{
xtemp = (float) sine_cosine[degrees-270][1];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[degrees-270][0];
ytemp = ytemp * -1;
break;
}

/* 315 - 360 */
xtemp = (float) sine_cosine[360-degrees][0];
xtemp = xtemp * -1;
ytemp = (float) sine_cosine[360-degrees][1];
ytemp = ytemp * -1;
}

ytemp = ytemp/32767;
xtemp = xtemp/32767;

xtemp *= (aspect_h*baselength);
ytemp *= (aspect_v*baselength);

*x += (int )xtemp;
*y += (int )ytemp;

}


Bill Buckels

unread,
Jul 26, 2009, 6:52:09 AM7/26/09