Assemblers are for hiding your work , not for faster code .

Because you may actually care about the speed of the instruction schedule you're writing. It may be easier to "lay out" the schedule by keeping its component parts separate.

Cheers, Brandon Van Every

In article , werty writes

Oh dear. Another one is born every minute!

-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ snipped-for-privacy@phaedsys.org

I would not employ him/her. I dare say it writes completely unmaintainable code.

You just don't get it, do you. When you write a computer program you are doing two things.

The first is to tell the computer what to do.

The second, and by far more important, is to tell other programmers what you are telling the computer to do. These other programmers (this includes you when you come back to your code 5 years down the line) all use one or more human languages. The closer you can get your code to look like one of these the less scope for error there will be.

Ian

Oh dear, the old self documenting code bollox. The important thing is for the code to be properly documented. This means there should be a design document which describes the TECHNIQUES the code is going to use to meet its requirements. The the code itself needs to be COMMENTED such that the IMPLEMENTATION of these techniques is clear to a reader. This is completely (computer) language independent.

Ian

...

..

Our friend Mr Werty reminds me of that wack-a-mole game that you can see at fairs and arcades. From time to time he pokes his head up and spouts incoherent points about something that makes little sense. The group tries to beat him back into his hole never quite nailing him on the noggin probably because he can't state his point eloquently enough.

Mr Werty, if you have "the next big thing", there are things you can do to convince us:

1. Get some help to express yourself in English or, if that's not possible, present your claims in your native language.
2. Use data and/or demos to back up your claims.
3. Never use hyperbole. For example, please prove to us that you're the worlds' greatest system programmer.
4. Keep it sane, relevant, measurable.

You sound like a lunatic. Maybe you have good ideas. Please put some effort into helping us understand your ideas.

JJS

With you so far.

Nope. Why do you think we have diplomats?

Cheers, Brandon Van Every

You appear to feel threatened by Mr. Werty. We don't really need to know about his pyschology or social role; those appear to be your issues and your fears. We don't need to respond to him at all. I responded to 1 technical point, because it did seem clear enough. He's prioritizing abstraction. Abstractions don't help if your problem domain must be handled concretely, though. I hope I've made him aware of that, or someone else if not him. Chasing abstractions is a common programmer's disease and very much a beginner's mistake. I'd say I've wasted 2/3 of my so-called career on it.

Cheers, Brandon Van Every .

Unless you comment. I figure the program flow and operations should be obvious even if you don't understand the programming language.

John

Abstraction has a place, but it is (as you have obviously found out) a drug that can allure many a programmer into the loss of many hours/days/weeks/months of their time in an inappropriate situation.

In the appropriate situation assembly is best. I have yet to find a situation where COBOL is best ;)

Cheers

PeteS

You missed the part about "leverage" ,,

when you put 2 opcodes together , then you have a Primative .

One day you want speed , the next day you want high level !

When you dont want to work at low level , you use Primative . " " want to work at lowest level , you use separate opcodes .

Understand ? You can use either method , depending on how you feel ?

But seriously , you really must use leverage , because you can unroll ALL modular code , no cost , no penalty . And you are not limited , you can choose !!

Why ?! I dont want to make you understand ,

i am here to compete with programmers , to produce .

You dont sound like producers . You sound like college professors .

__________________________

I am the worlds greatest systems programmer , because

i want to compete with you to keep my title .

How can i compete , if you refuse to compete ?

I have not met any here who want to show me

their stuff , to better mine ....

Compete , produce ......

ARM PC with 120GB HDD_USB 1024 by 768 Video accelerator to drive large Monitor thru a HDMI/DVI-d cable . DVDD burner , no copy protection .

No Linux , No M$ , No Text , No English .... Boots from 4MB , external SRAM in 1 second .

So why not roll it all - design specs, hardware notes, history, comments, code - a single source file? That's what I do. So I don't worry about different versions of different files not matching, or of having the source but losing the background info.

John

The idea of "folding" ASM code, and visualizing it in expanded or collapsed state, could be useful for ASM coding. But the visualization would need some intelligence regarding the schedule. I think if there's tons and tons of instructions that need to be scheduled precisely for performance purposes, you're not accomplishing anything. It would be the error of desiring lotsa flexibility when in fact there's a specific scheduling task you need to get done. In that case it's easier to just lay things out "flat."

Wish I had more time for compiler design. I've long been interested in the problem of combining various instruction streams to gain performance.

Cheers, Brandon Van Every

Well, there's a reason for that. People who are *really* productive aren't even posting here, they're worrying about their own problems. Competing with you isn't one of them. In fact, such people would describe competing with you as a pointless waste of their time. But I'm happy to get the occasionally useful idea about ASM code from you. That's time effective.

Cheers, Brandon Van Every

Support for fixed point calculations is more or less nonexistent in most programming languages, except COBOL and possibly PL/1.

Paul

Ada also supports fixed-point calculations. But I expect that typical COBOL compilers support larger fixed-point numbers than typical Ada compilers do, because the applications are different (money quantities in COBOL, physical quantities in Ada).

Who said ANYTHING about self documenting code. I certainly NEVER mentioned it. Writing your source code in a clear manner; using meaningful, natural language variable names; avoiding clever constructs and multi level indirections are what I was alluding to. You can have all of the design documentation in the world but if you follow the guidelines set by the obfuscated C enthusiasts then there is no hope for anybody.

Ian

John,

how long do your files get? In lines or bytes, whichever is easier for you to say. I can see how this could be a pretty useful approach up to say 10k lines or so. I personally tend to limit the length to 1-2k lines per file, but this in a different context (and for hundreds of files; some of them really short - but massively included etc.). I also wonder what time does it take your assemler to handle one of your large files nowadays (I just don't know what is out there for a PC), seconds, milliseconds?

Dimiter

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

------------------------------------------------------

John Lark> >