16-bit + basic programming

[M.Pathma]

Hi,

I am currently developing my project with 8-bit micro and would like to
explore the 16-bit or the ARM series, my problem is I am "expert" in Basic
language ... and "dump-stupid" in C-complier.

Can anyone please point me to a 16-bit/ARM Basic complier and chip
manufacture.

I have been searching Basic Complier & development board for ARM6/7/8/9.

Any help in this area will be appericiated.

Thanks
M.Pathma
MALAYSIA.

 

[PeteS]

Hi,

I am currently developing my project with 8-bit micro and would like to
explore the 16-bit or the ARM series, my problem is I am "expert" in Basic
language ... and "dump-stupid" in C-complier.

Can anyone please point me to a 16-bit/ARM Basic complier and chip
manufacture.

I have been searching Basic Complier & development board for ARM6/7/8/9.

Any help in this area will be appericiated.

Thanks
M.Pathma
MALAYSIA.

I would suggest you *learn* C. It's not really that difficult
(especially if you know hardware). Much depends on what you mean by
BASIC, of course, but I have to say I heartily agree with this quote
from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."

He's talking more about the issues with BASIC than the ability of good
minds

See this page for more quotes:
http://en.wikiquote.org/wiki/Edsger_Dijkstra

There are voluminous resources on C, and if you want to do any hardware
centric computing, BASIC makes it 'difficult' to say the least (well,
you have peek and poke, but that's rather a kludge).

I will agree that VB has helped somewhat (it's actually structured,
after a fashion), but there are subtle (and not so subtle) issues with
it that make me personally avoid it like the plague.

Cheers

PeteS

 

[John Jardine.]

[...]

I would suggest you *learn* C. It's not really that difficult
(especially if you know hardware). Much depends on what you mean by
BASIC, of course, but I have to say I heartily agree with this quote
from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."

Dijkstra's no legend to me. In my eyes he's just a fart programmer.
He's absolutely right though!. Prior exposure to BASIC completely destroys
any hope of a subject becoming pliant enough to accept "C" brainwashing.
I know of these things from personal experience, as at an early age I was
fortunate enough to be suckled from the warm and bountiful teat of Basic.

It's not that I've haven't made valiant efforts to align myself with the C
language. Lord, oh Lord, how I've tried. I spent a whole 3 months last year
back engineering a C programmers 'work' and for the past 2 weeks have been
writing a hardware control prog' in C. But ... no matter how hard I try to
ignore my preconditioning, I still look at the C stuff that I or other
people have written, or read the programming reference manuals and can only
ever see screeds of contrived-to-be-awkward' text constructs. Most of all
though, I look at the stuff and think "god that is ugly and impenetrable".
John Larkin had it spot on, with a comment that it's a language composed of
punctuation marks.
(no I'm not a programmer).
john

 

[Fred Bloggs]

I am currently developing my project with 8-bit micro and would like to
explore the 16-bit or the ARM series, my problem is I am "expert" in Basic
language ... and "dump-stupid" in C-complier.

Can anyone please point me to a 16-bit/ARM Basic complier and chip
manufacture.

I have been searching Basic Complier & development board for ARM6/7/8/9.

Any help in this area will be appericiated.

As a last resort, you can "develop" your program in BASIC and then use a
translator such as http://rjpcomputing.com/?page_id=6/ . Make sure you
use a compiler with an IDE ( integrated development environment) that
allows breakpoints and sissy-stepping through every little thing you do.

 

[Ken Smith]

As a last resort, you can "develop" your program in BASIC and then use a
translator such as http://rjpcomputing.com/?page_id=6/ . Make sure you
use a compiler with an IDE ( integrated development environment) that
allows breakpoints and sissy-stepping through every little thing you do.

.... or a "disintegrated" debugger that does the same sort of stuff.

One thing to check is how fast the debugger gets in and out of a single
step or break point. If it is over about 5 seconds, worry about how much
time you will spend waiting.

You want to be able to do the following:

Go until one of N breakpoints is hit. Where N>1.

Step by one source statement

Step by one instruction

View the contents of a variable as understood by the compiler

View the contents of memory as a hex dump

View the code as disassembled instructions

View the content of any special function registers


The following are nice to also have:

Conditional break points so you can have a variable's value checked

Go till the routine returns

Change a variable's contents on the fly so you can continue testing after
the first bug is found

Looping constructs more complex than just the conditional breakpoints sort
of like "go til line 57; variable i=7; loop until j=32"

The ability to write what you do to a log-file

 

[Luhan]

... or a "disintegrated" debugger that does the same sort of stuff.

One thing to check is how fast the debugger gets in and out of a single
step or break point. If it is over about 5 seconds, worry about how much
time you will spend waiting.

You want to be able to do the following:

Go until one of N breakpoints is hit. Where N>1.

Step by one source statement

Step by one instruction

View the contents of a variable as understood by the compiler

View the contents of memory as a hex dump

View the code as disassembled instructions

View the content of any special function registers


The following are nice to also have:

Conditional break points so you can have a variable's value checked

Go till the routine returns

Change a variable's contents on the fly so you can continue testing after
the first bug is found

Looping constructs more complex than just the conditional breakpoints sort
of like "go til line 57; variable i=7; loop until j=32"

The ability to write what you do to a log-file

I agree, debugging facilities are most important. Most all of my PC
software is still written in Borland Turbo C. They invented (as far as
I can tell) the integrated debugger environment.

Code - Compile - Run - Ooops - Debug - Code ... etc.

Luhan

 

[PeteS]

[...]

I would suggest you *learn* C. It's not really that difficult
(especially if you know hardware). Much depends on what you mean by
BASIC, of course, but I have to say I heartily agree with this quote
from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."

Dijkstra's no legend to me. In my eyes he's just a fart programmer.
He's absolutely right though!. Prior exposure to BASIC completely destroys
any hope of a subject becoming pliant enough to accept "C" brainwashing.
I know of these things from personal experience, as at an early age I was
fortunate enough to be suckled from the warm and bountiful teat of Basic.

It's not that I've haven't made valiant efforts to align myself with the C
language. Lord, oh Lord, how I've tried. I spent a whole 3 months last year
back engineering a C programmers 'work' and for the past 2 weeks have been
writing a hardware control prog' in C. But ... no matter how hard I try to
ignore my preconditioning, I still look at the C stuff that I or other
people have written, or read the programming reference manuals and can only
ever see screeds of contrived-to-be-awkward' text constructs. Most of all
though, I look at the stuff and think "god that is ugly and impenetrable".
John Larkin had it spot on, with a comment that it's a language composed of
punctuation marks.
(no I'm not a programmer).
john

One can write horrible code in any language, of course. I have seen
plenty of it in most languages, especially from hardware designers (of
which I am one) but often from software engineers.

The difference (for the OP) is that C is supported in many forms for
this target, whereas BASIC is not.

I will say that properly written C is clean and readable, but to
someone who expects to find everything defined in one place it *will*
be difficult. Composed of punctuation? good point, but so is Verilog
and VHDL.

C is not going to save you from yourself; in this sense it is an
assembly language programmer's high level language. You are completely
free to trash the entire system (but then you are free to do that in
assembly too), but then it was written as a systems level language.

There are many arguments for and against just about every language in
existence, many of them well deserved. One uses the language that works
best for a particular situation.

An old tagline was 'Unix is user friendly. It's just very particular
who it's friends are', and there's a lot of truth in that. As C was
designed by the same person as co-wrote the original Unix[tm] [dmr],
it's hardly surprising to find the same arguments

Cheers

PeteS

 

[PeteS]

[...]

I would suggest you *learn* C. It's not really that difficult
(especially if you know hardware). Much depends on what you mean by
BASIC, of course, but I have to say I heartily agree with this quote
from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."

Dijkstra's no legend to me. In my eyes he's just a fart programmer.
He's absolutely right though!. Prior exposure to BASIC completely destroys
any hope of a subject becoming pliant enough to accept "C" brainwashing.
I know of these things from personal experience, as at an early age I was
fortunate enough to be suckled from the warm and bountiful teat of Basic.

It's not that I've haven't made valiant efforts to align myself with the C
language. Lord, oh Lord, how I've tried. I spent a whole 3 months last year
back engineering a C programmers 'work' and for the past 2 weeks have been
writing a hardware control prog' in C. But ... no matter how hard I try to
ignore my preconditioning, I still look at the C stuff that I or other
people have written, or read the programming reference manuals and can only
ever see screeds of contrived-to-be-awkward' text constructs. Most of all
though, I look at the stuff and think "god that is ugly and impenetrable".
John Larkin had it spot on, with a comment that it's a language composed of
punctuation marks.
(no I'm not a programmer).
john

One can write horrible code in any language, of course. I have seen
plenty of it in most languages, especially from hardware designers (of
which I am one) but often from software engineers.

The difference (for the OP) is that C is supported in many forms for
this target, whereas BASIC is not.

I will say that properly written C is clean and readable, but to
someone who expects to find everything defined in one place it *will*
be difficult. Composed of punctuation? good point, but so is Verilog
and VHDL.

C is not going to save you from yourself; in this sense it is an
assembly language programmer's high level language. You are completely
free to trash the entire system (but then you are free to do that in
assembly too), but then it was written as a systems level language.

There are many arguments for and against just about every language in
existence, many of them well deserved. One uses the language that works
best for a particular situation.

An old tagline was 'Unix is user friendly. It's just very particular
who it's friends are', and there's a lot of truth in that. As C was
designed by the same person as co-wrote the original Unix[tm] [dmr],
it's hardly surprising to find the same arguments

Cheers

PeteS

Dijkstra is also credited with saying 'I have yet to meet a C compiler
easier to use than eating soup wth a fork'. He was an equal opportunity
criticiser

Certainly trying to decipher the warning/error outputs of cc [or gcc
for that matter] is one of life's challenges

Cheers

PeteS

 

[Ken Smith]

I agree, debugging facilities are most important. Most all of my PC
software is still written in Borland Turbo C. They invented (as far as
I can tell) the integrated debugger environment.

Code - Compile - Run - Ooops - Debug - Code ... etc.

If they didn't invent it, it sure is a standard against which others can
be compared. As of yet I haven't seen one that was better. There is now
"free pascal" with an almost perfect copy of the Borland IDE. It runs on
many systems.

Also: The Pascal compiler is very fast. It looks to be a classic
recursive decent compiler where the first error stops it.

 

[Luhan]

If they didn't invent it, it sure is a standard against which others can
be compared. As of yet I haven't seen one that was better. There is now
"free pascal" with an almost perfect copy of the Borland IDE. It runs on
many systems.

Also: The Pascal compiler is very fast. It looks to be a classic
recursive decent compiler where the first error stops it.

I wrote a C cross compiler modeled after Borland. It ran under DOS
and sent out Z80 code to the target on bi-directional bit-bang lines.
There was no hardware emulator, but it did source level trace with
variable watch. Only 3 functions were needed at the target: Write
memory location with data, Read data from location, Goto to location.

Since the compiler had access to the symbol table, variables could be
asked for by name and the debugger just looked up there address in the
target and requested that location.

Trace was done by reading a known location specified by the source
line, writing in a 'trap' instruction, and executing from the current
location until the trap was reached.

The total program size was 83K which included the editor, compiler,
debugger, and code generators for both Z80 and 68000. All written in
Borland Turbo C.

Luhan

 

[PeteS]

I wrote a C cross compiler modeled after Borland. It ran under DOS
and sent out Z80 code to the target on bi-directional bit-bang lines.
There was no hardware emulator, but it did source level trace with
variable watch. Only 3 functions were needed at the target: Write
memory location with data, Read data from location, Goto to location.

Since the compiler had access to the symbol table, variables could be
asked for by name and the debugger just looked up there address in the
target and requested that location.

Trace was done by reading a known location specified by the source
line, writing in a 'trap' instruction, and executing from the current
location until the trap was reached.

The total program size was 83K which included the editor, compiler,
debugger, and code generators for both Z80 and 68000. All written in
Borland Turbo C.

Luhan

Turbo C was perhaps one of the best compilers I ever used. Lean and
mean, excellent documentation. My first copy was 'borrowed' from a
friend in college c. 1988 (the price was $50 if I recall correctly) and
was the first decent IDE I ever saw - in my opinion, it still beats
many of the so-called IDes out there today.

Cheers

PeteS

 

[Joe Soap]

In response to what PeteS <[email protected]> posted in

One can write horrible code in any language, of course. I have seen
plenty of it in most languages, especially from hardware designers (of
which I am one) but often from software engineers.

The difference (for the OP) is that C is supported in many forms for
this target, whereas BASIC is not.

I will say that properly written C is clean and readable, but to
someone who expects to find everything defined in one place it *will*
be difficult. Composed of punctuation? good point, but so is Verilog
and VHDL.

C is not going to save you from yourself; in this sense it is an
assembly language programmer's high level language. You are completely
free to trash the entire system (but then you are free to do that in
assembly too), but then it was written as a systems level language.

There are many arguments for and against just about every language in
existence, many of them well deserved. One uses the language that
works best for a particular situation.

An old tagline was 'Unix is user friendly. It's just very particular
who it's friends are', and there's a lot of truth in that. As C was
designed by the same person as co-wrote the original Unix[tm] [dmr],
it's hardly surprising to find the same arguments

The two languages I write in these days, from choice, are C and Pascal.

Pascal tries to stop me from doing what has to be done: C lets me do what
ought not to be done.

Choose your evil!

 

[Brian]

He's talking more about the issues with BASIC than the ability of good
minds

See this page for more quotes:
http://en.wikiquote.org/wiki/Edsger_Dijkstra

There are voluminous resources on C, and if you want to do any hardware
centric computing, BASIC makes it 'difficult' to say the least (well,
you have peek and poke, but that's rather a kludge).

I will agree that VB has helped somewhat (it's actually structured,
after a fashion), but there are subtle (and not so subtle) issues with
it that make me personally avoid it like the plague.

Cheers

The best route is to learn generic object oriented programming methodology,
then C. Helps kill off the BASIC thinking.

 

[Luhan]

The best route is to learn generic object oriented programming methodology,
then C. Helps kill off the BASIC thinking.

I once worked with a guy who got hired because my boss saw him in a
bookstore wearing a t-shirt that said:

C is to C++ as Brain is to Brain Tumor.

Luhan

 

[Luhan]

The two languages I write in these days, from choice, are C and Pascal.

Pascal tries to stop me from doing what has to be done: C lets me do what
ought not to be done.

Yes indeed Sahib, you have that most exactly correct !

Luhan

 

[Brian]

I once worked with a guy who got hired because my boss saw him in a
bookstore wearing a t-shirt that said:

C is to C++ as Brain is to Brain Tumor.

Luhan

About correct, though. Its that age old concept of taking something simple
and useable... and screwing with it until its so f*'d up, its useless.

 

[David Brown]

About correct, though. Its that age old concept of taking something simple
and useable... and screwing with it until its so f*'d up, its useless.

http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

 

[joseph2k]

[...]

I would suggest you *learn* C. It's not really that difficult
(especially if you know hardware). Much depends on what you mean by
BASIC, of course, but I have to say I heartily agree with this quote
from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."

Dijkstra's no legend to me. In my eyes he's just a fart programmer.
He's absolutely right though!. Prior exposure to BASIC completely destroys
any hope of a subject becoming pliant enough to accept "C" brainwashing.
I know of these things from personal experience, as at an early age I was
fortunate enough to be suckled from the warm and bountiful teat of Basic.

It's not that I've haven't made valiant efforts to align myself with the C
language. Lord, oh Lord, how I've tried. I spent a whole 3 months last year
back engineering a C programmers 'work' and for the past 2 weeks have been
writing a hardware control prog' in C. But ... no matter how hard I try to
ignore my preconditioning, I still look at the C stuff that I or other
people have written, or read the programming reference manuals and can only
ever see screeds of contrived-to-be-awkward' text constructs. Most of all
though, I look at the stuff and think "god that is ugly and impenetrable".
John Larkin had it spot on, with a comment that it's a language composed of
punctuation marks.
(no I'm not a programmer).
john

If you think C is bad you ought to try APL. It is so full of punctuation
marks and contrived punctuation marks that only impenetrable function and
variable names are left. It even takes special software (previously done
in hardware) to even view it. It has its own extensive character set (500+
symbols i think).

 

[Ken Smith]

If you think C is bad you ought to try APL.

I think APL is a good language. "Life is too short to spend it coding DO
loops". In many ways it is like assembly programming on a machine that
just happens to do arrays automatically.

It is so full of punctuation
marks and contrived punctuation marks that only impenetrable function and
variable names are left.

Most implementations allow longish names so you can make the names mean
stuff.

For those that done know: In APL, funtion calls are written:

function
function right
left function right

Where "left" and "right" are arguments.


This makes:

Mary had a little lamb, some potatoes and some carrots

a perfectly good APL statement. This is all done without a single
#define. Now I think you can see that APL is a truely lovely language.

 

[jasen]

John Jardine. wrote:

If you think C is bad you ought to try APL. It is so full of punctuation
marks and contrived punctuation marks that only impenetrable function and
variable names are left. It even takes special software (previously done
in hardware) to even view it.

a standard VGA display could support 512-symbol fonts in text mode,
(trading blink for the extra bit of character iirc)

It has its own extensive character set (500+ symbols i think).

the original lisp machines used an extended character set too.
Lambda was a single symbol, dunno about "car" and "cdr"

perl can be pretty indecipherable too and it's all ASCII.

ISTM that any unicode text editor would be fine for APL or LISP these days.

Bye.
Jasen