> >I have to wonder about the speed increase, though. C is much more
> >flexable, and it could very well be that it some instances, a speed
> >increase could be found.
> It all depends on what you are trying to do. I generally found most
> versions of C (I used to use Laser C quite a bit) could give me a
> somewhat faster executable (especially with floating point math) and
> almost always a _smaller_ executable than my best efforts with GFA.
> But those relatively small gains came with a penalty in development
> and debugging time. A 'real' C-guru would be more efficient, of course.
> Make no doubt about it, C _is_ more flexible but it ain't a Godsend
> for every programming chore. The skills of the programmer are MUCH
> more important than the language specs.
I agree that C is more flexible when compared to BASIC.
<begin slightly-off-topic waffle>
Some years back, a "scurrilous" copy of Laser C managed to find me. I
tried it out, and liked the compiler. I was using a Mega 4 at the time,
and compilations were _FAST_ (until one reached 1500+ lines - then it
really slowed down)
The environment was good, but, unfortunately, took too many shortcuts. In
short, it was a little "flaky". After every fourth or fifth compile, I
would experience an "Exception 5" or "Exception 4" (division-by-zero and
"illegal instruction" errors), and the machine would hang.
The source-code de* was great. Unfortunately, it was an extra-cost
option, which I believe few took up. The ability to step through C source
code, press a few keys and then be looking at 68000 assembly language was
great. Another few keystrokes and I could be looking at C source code
again. This could happen at any time whilst debugging.
At the time I received it, I was part way through paying for a hard-drive.
I kept the compiler and used it whilst I saved the pennies to purchase the
compiler from a local retailer.
As a non-ANSI compiler, it was quite good. It was about to be upgraded to
ANSI standard when I received my copy.
I fronted up with the cash to purchase it from my local retailer. They
didn't have it in stock, but they told me of the soon-to-be ANSI upgrade.
I waited for it, but nothing came.
So, I bought Lattice C v5 from Hisoft, and disposed of Laser C (by
destroying all traces of Laser C that I had). Compared to Laser, it
[Lattice] was a disc-bound behemouth, sluggish and somewhat temperamental
until configured correctly.
I currently use Lattice C v5.6 from Hisoft, which, in my opinion, is a
much better product than v5. It is still a bit of a mongrel to set up, but
is more stable and more productive than the earlier version. It just isn't
very friendly when trying to run installed tools under MultiTOS. The
linker is a pain as well, because if I have made it resident, the second
or third time it is run, it will hang the machine completely under
MultiTOS. It's not that I do not have enough RAM - I frequently have
between ten and twelve megabytes free when programming under MultiTOS with
( Memo to Hisoft : Some of us run with MultiTOS all day, and require tools
which do not hang the computer and require a reboot. Your language
products seem to be "MTOS compatible" [runs under MTOS], but not "MTOS
friendly" [gets on well with other co-resident, simultaneously running
software]. Please fix as part of your "on-going support" for Atari
products. I, for one, will gladly pay a reasonable price to upgrade. )
<end of slightly-off-topic waffle>
Recently, I was asked to produce some code for Hisoft BASIC - to colour
expand 4-bit (16 colour) graphics to 8-bit (256 colours) and 16-bit
True-colour (65536 colours) for the Falcon running a screen expander. At
the time, I believed that the images could be quite large, possibly over
half-a-megapixel in size, so I coded it in Devpac 3.1 (an assembler).
In order to do so, I needed to know what sort of machine-code Hisoft Basic
produced - how parameters were passed, what CPU registers were sacred, how
results were to be returned, and so forth.
Looking at it, Hisoft Basic has a faster compiler, but produces worse
machine code than most C compilers I have used.
(The manual accompanying Hisoft Basic even has a few errors about how to
produce assembly-language modules for it. "Parameters passed in reverse
order" means two different things, depending on whether you are coding
for Lattice C or Hisoft Basic)
Simple bit-fiddling, computation-intensive or low-level code is very much
poorer when produced by Hisoft Basic.
The best results are achieved when using a combination of BASIC, C and/or
assembler, using the strengths of each one.
Commented source code can also alleviate the development/debugging time
As can a source-level de*. Which the version of 'Mon' bundled with
Hisoft products definately isn't.
I should qualify that last sentence - Hisoft Basic, Lattice C and Devpac
3.1 allow you to compile with debugging info included in the programs.
Unfortunately, Mon [the de*] will only take note of the first lot of
debug info. If your code is at all like mine - spread throughout more than
one source file - then you are out of luck. As you step through your
program, a "source" window will stay in sync with the "disassembly" window
- but only for the one "debuggable" module, everything else is ignored.
(Laser C was a lot better in this regard - I once had a 50-module C
program to debug, and every one of those 50 modules were debuggable at the
C source level. This is not possible in Hisoft language products, as far
as I am aware).
I do agree with Hutch about the skill of the programmer being important. A
good programmer can make a computer do wonderous things when using the