Re: Hey Mr. Hyde!

From: wolfgang kern (nowhere_at_nevernet.at)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 23:36:19 +0100

Hi Beth,

| > And one more generation of programmers who have no idea
| > what's a HW-pin and what's a SW-flag :)
| > [see the regular FAQs asked by confused programmers]
| > Ok, user-level programmers don't need to know anyway.
| > ASM is the proper language for man-machine-link programming,
| > so teaching ASM should start with a minimum HW-level rather
| > than with the obligatory winApi-usage in HLL-style.

| Yes, indeed...totally...
| _Except_ it ain't Randy to blame...as you use your own "home-made" OS,
| wolfgang, then you might not experience the true cause of these things
| often enough to realise that Randy is NOT to blame at all...

| Under modern OSes (not just Windows, Linux and others are exactly the
| same on this point :), they are all "layered" and "protected" and
| everything _must_ be done via "API" because this is "portable" and
| "convenient"...blah-blah-blah...

Yes, it's not a question of HLA or RosAsm.
It is a problem of all HLL- and ASM-tutorials around.

| You read Randy's 16-bit AoA, wolfgang?
[..] particular
| Randy's stuff was very _good_ on that score, compared to most :)

Ok, even with the opposite direction view,
there are some good legacy port examples.
But I use and prefer RBIL-styled bit-descriptions,
as it show facts on a glimpse.

| And, also, Randy's putting together a
| "how to write device drivers in Linux" book on Webster too...
| ... near the hardware on modern OSes ...

Near to HW with "modern" OS?
THIS IS the point I try to declare as almost impossible.

Windoze/linux/and similar use the EDP-philosophy,
which is based on multi-user protection-levels and the
wrong idea of having the opportunity to run several HW-tasks
at the same time. Even a multi-processor machine can't act the
hardware from two sides at a very moment.
All these 'locking, instance- and task-switches' are useless and
paranoid and seem just to come from the misunderstanding of the
bus-structures, CPU-pipes and peripheral connections.

| ... Might as well go the short distance to actually learning that
| too and then I can _really_ 'write great code'!"...
I think you mean 'write huge code' here :)

| Actually, you're a Germanic fellow, yes?

NOO! Austrian with Celtic+Gipsy+Slavian origin! ;)

| Would I be correct in guessing that you once owned a C64..

Yes, I still owe two working sets and a large amount of 5.25 disks.
But they are of rare use this days, as the kids prefer the
convenience of a HD.

[..]| important when 64KB was your _entire RAM_ ;)"...

Right, I started very quick with ASM- and HEX-coding on C64 ..

| Those "glory days" and the "Golden Age" won't come around again..

why not?
the KESYS-core is limited to 128 KB, and still 60% free :)

[Randy's books]
Granted, Randy teaches programming the way he think it's best.
But Randy, Rene, Hutch and others share the same target:
the M$/Linux/BoringLand way with the 'lib-portability' feature.

ASM isn't a language to create portable source-code,
it is a CPU(group)-specific language.

| This ain't "low-level" at all by our standards, right, wolfgang?

Right!

| I mean, you want to write some pixels?
[...]
| incredible pain that should be avoided at all costs...that's the kind
| of "Direct" that "DirectX" is ;)...

Exact. And that's why I wrote my own 'native graphics module'.

| Do you, in fact, recognise this _at all_, wolfgang, in comparison to,
| say, requesting a "linear framebuffer" in VESA and then just plotting
| your pixels with "MOV" from the supplied address for where the
| framebuffer starts? Heck, even with "banking" and calling some routine
| to switch "banks" is a whole lot less bother than dancing around the
| place with "pens" and "brushes"...totally _abstract_ non-entities
| invented to keep VB programmers writing spreadsheets happy...it's only
| pixels, people! Really, it's _MORE_ complicated to deal with this
| "direct which isn't at all direct" nonsense...

Programmers convenience vs. code performance ...

| And this ain't Randy...nope, this is not even Microsoft...this is
| "modern layered OS architecture"...this is everything being coded in C
| by those who've probably only just qualified on their "VB for dummies"
| course three weeks earlier and are kind of "learning C on the job" as
| they go...
[..]

Fully agree.

| Surely, talking to you, wolfgang, I am "preaching to the converted" a
| touch, as you so don't like the prospect of all this that the only
| feasible way to avoid it all was to code your own systems
| software...but over here in Windowsland, the options are limited, the
| operating system crap and this stuff _does_ amount to about the best
| you can do...

Perhaps that is it what I can't understand,
there is a lot of power, knowledge and experience in this NG,
why will everyone except me continue on the ill path?
We could create a "new ASM library standard" and write only
needed functions (in plain ASM) to it.
We also could write it for several different OSes.
But I'd not recommend to use the parameter-pushing method...

[RosAsm...]
| It's not just ".if"...or even ".Else_if" for that matter...we've now
| even got "On XXXX, call YYYY"...
| And look above and note what mnemonics you will recognise...exactly
| "mov", "movzx" and "call"...the "push" stuff is all disguised inside
| the HLL calling convention "call" macro, by the way ("call
| 'USER32.SendMessageA', D$DebugDialogHandle, &WM_COMMAND, 9, 0" is
| really MASM's "INVOKE SendMessageA, DebugDialogHandle, WM_COMMAND, 9,
| 0" with all the "parameters" being automatically "pushed" as part of
| the macro :)...

Yeah, macros can be neat, if I can see what's included there ...
I have to write some windoze-code right now and I already
collected MASM32, RosAsm114 and FASMW+ODB.
All I need to learn yet are the top thirty API-calls.
Which would be your top 30 ? (GUI/menu,dialog/fileIO/modem/printer)

| The point here - not an attack on Rene or Randy because _NEITHER_ are
| to blame for this, as it all comes from device drivers and evil old
| Sir Bill - is that the code is reduced to "MOVe values to / from
| memory, PUSH paramters, CALL APIFunction...PUSH parameters, CALL
| OtherAPIFunction...PUSH parameters, CALL AnotherAPIFunction...MOVe
| results into memory...PUSH parameters, CALL
| YetAnotherAPIFunction"...blah-blah-blah...you get the message, I
| trust...it's all just a series of CALLs into a _HLL library_...

YES! here is the place where the dog is buried!

| In fact, looking at this kind of thing without knowing where it's
| coming from, you'd be forgiven for looking at it and thinking it might
| be the output of a _BASIC interpreter_...yeah, rather than compile
| anything, it's all just reduced by the _interpreter_ into a series of
| CALLs into HLL library routines...FORTH must feel right at home under
| this architecture because many implementations reduce things still
| further by recognising the pattern and only bothering to store the
| order of the CALLs as a "program" with a small chunk of code attached
| on that reads the list of CALLs and repeats this same old, same old
| pattern over and over: "PUSH parameters, CALL APIFunction, MOV results
| into variables"...repeat until brain-dead from it all...

YES! here starts the smelling!

| And the true "battle" here between Rene and Randy is that Rene's
| tactic is confrontation, Randy's tactic is subversion from the inside,
[..]
:) well defined..

[..]

| Assembly coding - least not "real assembly" coding - is not just a
| case of using the mnemonics...it's about _HOW_ you use them...the
| "level" you approach a problem at...your "machine thinking" about
| solutions ...why don't we see enough of that being discussed?

We can ignore the battle and discuss code-solutions...

| Syntax is the _LEAST_ important thing here, in fact...
| who cares what "colour" your car is when it's constantly broken
| down and won't go anywhere?

Yes.

| > BTW: I have to apologize for my previous notes about
| > the 'go Webster'-spam,
| > your links to other ASMs are quite useful.
| > If you would add RosAsm to your list,
| > this may end a long lasting war.
| > But I'm afraid this is just an illusion :)
| An illusion, unfortunately...because Randy _was_ accomodating and
| supportive in the beginning to Rene and he threw it all back in
| Randy's face...plus, the "other links" section has _always_ had a link
| to SpAsm / RosAsm...

[...]
Right Beth, we wont celebrate Guy-Day every day...

__
wolfgang

Quantcast