Re: Disobeying jet engines - why?

This is getting ever more true. Keeping the ALU pipeline stall rules
satisfied is a challenging problem for the guys doing optimising
compilers for a range of target CPUs (even ones in the same nominal
family).

Indeed. But I was talking programming, not using someone elses
libraries.

I find it odd here that I am jumping to the defence of C when I usually
am on the other side of the argument. But there can be no denying that C
is way more productive for software development than assembler.

No denying of what. You argue without saying what you are arguing
about. Which assembler? X86? Of course C is a better language.
PIC? Anything is better (as far as I have seen, that is, just looked
at the
PICs a long time ago).
What I use is something you do not know and have never had access
to. It looks much of the time like 68k assembler, but has grown
further
and I take advantage of a library built over the years which no
compiler
matches. At places it looks like higher level than C...

And that strongly typed languages can prevent a fair proportion of the
human error that inevitably creeps into software development. The more
faults you can find by static analysis the better for all concerned.

That's the key behind C - typing problems. Back then keyboards were
far
from todays (todays good ones, that is) and 2400 bpS were common.
This makes the choice of the C syntax a valid choice for its time, but
not a good one overall.

Yeah right. I am reminded of the Klingon programmer page:

http://www.sjbaker.org/humor/klingon_programmer.html

Well you enter an argument without understanding what the other side
says.
I am the last person any of these would apply to.

I have numerous things written, we can do a comparison of equivalent
pieces
of code if you do not just take my word :-).

OK. Lets see you write a Quine in the assembly language of your choice.

I chose my language carefully. It took me 1 line and a minutes typing.

So did I. It took me 0 lines of programming (0 seconds).
Just went to the directory and opened the source I wanted to.

Again, there is a difference between programming and using a computer.
The example you chose is not one of programming.

Let's try it again, have a look at this:

http://tgi-sci.com/y2demo/

How long would it take a typical programmer to do that?
I did not put DPS on it (although I could have), I only linked in some
hex/dec etc. tiny things I needed. The rest is done in VPA, pretty
much
after John Larkins recipe (no preemptive scheduler), I was curious.
I even brought that a little further, I used no IRQ at all (!). OK,
the
deep FIFOs the 5200 has helped a lot in that. And no, there is
no waiting for I/O and stalling anything like someone in the thread
suggested about Johns method, if one does not program a waiting
loop in it it does not go into a wait loop... :-).
I coded this within 2 monts after I had the board (first time for this
processor) up and running with my debugger and under control with
my JTAG tools for boundary scan (which took me another month
or two, not sure now).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Martin Brown wrote:
In message
<06c03999-6db8-4676-9c8e-f227368193bb@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Didi <diditgi@xxxxxxxxx> writes
eh, using C, with the modern compilers highly optimising,
they 'know' the processor', may actually improve performance, and reduce
chances of errors that could have occurred by misunderstanding some
CPU features
by an asm programmer.

This is getting ever more true. Keeping the ALU pipeline stall rules
satisfied is a challenging problem for the guys doing optimising
compilers for a range of target CPUs (even ones in the same nominal
family).

It may, if the programmer is not up to the task. Calling some library
functions
using some C hyeroglyphs is a lot less demanding than writing code,
this
is obvious.

If you are developing algorithms the last thing you need is to be
hampered by the opaqueness of the representation. You might as well
argue that real men should just use hex and memorise all the opcodes
too.

The reason that FORTRAN was so spectacularly successful was that it made
complex scientific computation accessible to anyone who could read and
write algebra rather than just for a handful of white coated acolytes of
the big iron god.

the C language is crippling the programmers, too much of their mind is
occupied
with the hoops they have to jump through in order to produce what they
need.

I find it odd here that I am jumping to the defence of C when I usually
am on the other side of the argument. But there can be no denying that C
is way more productive for software development than assembler.

And that strongly typed languages can prevent a fair proportion of the
human error that inevitably creeps into software development. The more
faults you can find by static analysis the better for all concerned.

Using a lower level language allows one to just type in a few lines
more
and be done with it, typically at a 10+ times better code efficiency

Yeah right. I am reminded of the Klingon programmer page:

http://www.sjbaker.org/humor/klingon_programmer.html

(and
at a similar coding efficiency, I would claim for myself).
I have numerous things written, we can do a comparison of equivalent
pieces
of code if you do not just take my word :-).

OK. Lets see you write a Quine in the assembly language of your choice.

I chose my language carefully. It took me 1 line and a minutes typing.

Regards,
--
Martin Brown

--
Posted via a free Usenet account from http://www.teranews.com
.

Relevant Pages

  • Re: when to use proc
    ... > point out that these are not real 80x86 assembly language statements. ... >> first assembler only app after reading the documentation. ... But remember I come from windows programming for 10 years. ... transition to Spasm was easy since the API I allready know a little about. ...
    (alt.lang.asm)
  • Re: Future of programming
    ... but again, let's not forget in my opinion the main purpose of programming, ... the more abstract the programming language ... code-generators, or even efficient compilers, which is not the case ... > fastest solution to the problem, then assembler is still needed. ...
    (alt.lang.asm)
  • A Friendly review of "Windows Programming in Assemble Language" chapter 3
    ... Programming in Assemble Language". ... Basically a commersial of HLA, and its ability to bridge the gap for asm ... ressurect HLA status to an assembler and positions HLA ...
    (alt.lang.asm)
  • Re: Survey
    ... >> There are a couple of things HLLs can do that an assembler cannot - ... >> programming population can read. ... No language can prevent the truly dedicated from writing unreadable ...
    (alt.lang.asm)
  • Re: Language design evolution vs. revolution
    ... Programmers prefer a language that is similar to what they ... I don't like typing lots of extra syntax that is unrelated to expressing ... I prefer structured programming. ... With NASM assembler, I don't have to understand what, why, or most ...
    (comp.lang.misc)
Loading