Some beginners seem to believe that they can learn Assembly
with an HLL, like, for example, HLA. Personaly, i do not
believe that this "Top-Down" way could have any advantage
on learning Assembly the normal way, that is, by using an
Assembler.

That being said, if beginners really want to take the Top-
Down way, they should choose, at least, an HLL making and
showing a clear difference in between what is Asm and what
is not, by the grace of some "inline Asm" delimiters, the
way, languages like C, Power Basic,... for example, do it,
if they wish to avoid confusion.


Betov.

< http://rosasm.org >

On Jun 13, 5:48 am, Betov  <spamt...@crayne.org> wrote:
> Some beginners seem to believe that they can learn Assembly
> with an HLL, like, for example, HLA. Personaly, i do not
> believe that this "Top-Down" way could have any advantage
> on learning Assembly the normal way, that is, by using an
> Assembler.
>
> That being said, if beginners really want to take the Top-
> Down way, they should choose, at least, an HLL making and
> showing a clear difference in between what is Asm and what
> is not, by the grace of some "inline Asm" delimiters, the
> way, languages like C, Power Basic,... for example, do it,
> if they wish to avoid confusion.
>
> Betov.
>
> <http://rosasm.org>


Most people would quickly quit if they started doing assembly language
from scratch.
Kinda like putting a .44 Magnum in a teen's hands who has never shot a
gun.

I started programming with batch files -> C -> C++ -> 16 bit assembly -
> 32 bit assembly

Outta here.

The top-down approach is useful for introducing assembly gradually and
allowing for meaningful examples to be compiled and tested
immediately.
On the other hand, the bottom-up approach requires a great deal of
instruction before any meaningful examples can be tested but offers a
challenge more rewarding for problem solvers.

One way of learning cannot satisfy everybody.  An interested party may
try and stick with the format that works best.  No matter which
approach is chosen, a beginner is advised to choose the assembler with
the best quality of existing pedagogy.

Of the existing ones, I can recommend HLA, MASM and NASM.

-sevag.k
www.geocities.com/kahlinor

My very first assembly program was copied verbatim from a book and
wasn't even an assembly program.

program helloWorld;
#include ("stdlib.hhf")

begin helloWorld;

	stdout.put ("Hello, World of Assembly Language", nl);

end helloWorld;


I wrote it without knowing anything about registers, instructions,
memory or addressing.  I needed absolutely no prior knowledge about
anything related to assembly to understand what this code did.
It didn't teach me anything about assembly either.  It did however,
give me some very valuable information.

1. I had figured out how to output data to the terminal without having
to know the inner workings of the operating system.
2. I had access to a library of functions that would assist me on this
journey.
3. I had read about 1 page to get this far.  I had before me a
structured plan from A to Z, step by step it would open up the world
of assembly language to me, just as the output of the very first
program promised:

"Hello, World of Assembly Language"

By the time I finished the first chapter, I had already learned about
registers, some simple instructions and had an introduction to the
memory subsystem and given the assurance of the structured exception
handler that would come in handy many times during the next few
months.
But this was just a teaser.  It got me hooked and now the book could
delve into more 'boring' parts without fear of losing me.

-sevag.k
www.geocities.com/kahlinor

"sevag.krikorian@gmail.com"  <spamtrap@crayne.org> �crivait 
news:1181885923.640011.179420@u2g2000hsc.googlegroups.com:

> My very first assembly program was copied verbatim from a book and
> wasn't even an assembly program.

Right. And this is part of what i am pointing to:


> program helloWorld;
> #include ("stdlib.hhf")
> 
> begin helloWorld;
> 
>      stdout.put ("Hello, World of Assembly Language", nl);
> 
> end helloWorld;

Right: This is plain HLL, but the point is that, if it had been
Assembly, the beginner would not noticed any difference. In the
C notation, at least, the beginner could have seen some:

    asm {

          }

delimiters which would help him understanding what is what.

Notice (but this is another story), that, in Assembly the above
example would be introduced as:

-------------------------------------------------
[Message: 'Hello, World of Assembly Language', 0
 Title: 'Hello', 0]

Main:
    push 0
    push Title
    push Message
    push 0
    call 'USER32.MessageBoxA'

    push 0
    call 'KERNEL32.ExitProcess'

  ; (Or whatever formal syntax...)
--------------------------------------------------

.... that, at least, the beginner would have been introduced
to Data declarations, to the most basic skeleton of a PE, to
the basics of an API call, and to two Assembly Instructions
.... instead of... nope, and instead of having to learn one
another HLL.

So, if the beginner already knows an HLL like C, best would
be, for him, to dig into the basic of Assembly with a couple
of Inline Statements, if he is unfortunately convinced that
the Top-Down approach is a correct one.


Betov.

< http://rosasm.org >

On Jun 15, 3:39 am, Betov  <spamt...@crayne.org> wrote:
> "sevag.krikor...@gmail.com"  <spamt...@crayne.org> �crivaitnews:1181885923.640011.179420@u2g2000hsc.googlegroups.com:
>
> > My very first assembly program was copied verbatim from a book and
> > wasn't even an assembly program.
>
> Right. And this is part of what i am pointing to:
>
> > program helloWorld;
> > #include ("stdlib.hhf")
>
> > begin helloWorld;
>
> >      stdout.put ("Hello, World of Assembly Language", nl);
>
> > end helloWorld;
>
> Right: This is plain HLL, but the point is that, if it had been
> Assembly, the beginner would not noticed any difference. In the
> C notation, at least, the beginner could have seen some:
>
>     asm {
>
>           }
>
> delimiters which would help him understanding what is what.
>
> Notice (but this is another story), that, in Assembly the above
> example would be introduced as:
>
> -------------------------------------------------
> [Message: 'Hello, World of Assembly Language', 0
>  Title: 'Hello', 0]
>
> Main:
>     push 0
>     push Title
>     push Message
>     push 0
>     call 'USER32.MessageBoxA'
>
>     push 0
>     call 'KERNEL32.ExitProcess'
>
>   ; (Or whatever formal syntax...)
> --------------------------------------------------
>
> ... that, at least, the beginner would have been introduced
> to Data declarations, to the most basic skeleton of a PE, to
> the basics of an API call, and to two Assembly Instructions
> ... instead of... nope, and instead of having to learn one
> another HLL.
>

Which would only introduce confusions since none of these instructions
have yet been explained, further you assume the user is working from a
Windows environment which is another thing not guaranteed.  Your
example throws upon the hapless beginner the "push" and "call"
instructions and before understanding what all this does, they need
some background information on the memory subsystem and stack
operation.  Things that require pages of reading to understand.


> So, if the beginner already knows an HLL like C, best would
> be, for him, to dig into the basic of Assembly with a couple
> of Inline Statements, if he is unfortunately convinced that
> the Top-Down approach is a correct one.
>
> Betov.

This is not an unworkable solution if there are instructional texts on
assembly that specifically uses the in-line approach using the syntax
of their favorite compiler.  Such information, if it exists for all
HLLs, may be hard to find so an aspiring student is better served
using HLA and NASM for multi-OS and/or MASM for Windows only; all of
which contain professionally written instructional texts specifically
tailored to those environments, using various approaches.  I would
throw in suggestions of other assemblers if they contained pedagogy of
similar quality.


-sevag.k
www.geocities.com/kahlinor

"sevag.krikorian@gmail.com"  <spamtrap@crayne.org> �crivait 
news:1181969420.720948.312060@o61g2000hsh.googlegroups.com:

>> Notice (but this is another story), that, in Assembly the above
>> example would be introduced as:
>>
>> -------------------------------------------------
>> [Message: 'Hello, World of Assembly Language', 0
>>  Title: 'Hello', 0]
>>
>> Main:
>>     push 0
>>     push Title
>>     push Message
>>     push 0
>>     call 'USER32.MessageBoxA'
>>
>>     push 0
>>     call 'KERNEL32.ExitProcess'
>>
>>   ; (Or whatever formal syntax...)
>> --------------------------------------------------
>>
>> ... that, at least, the beginner would have been introduced
>> to Data declarations, to the most basic skeleton of a PE, to
>> the basics of an API call, and to two Assembly Instructions
>> ... instead of... nope, and instead of having to learn one
>> another HLL.
>>
> 
> Which would only introduce confusions since none of these instructions
> have yet been explained,

Introducing and explaining instructions is one of the very true
purpose of any Assembly Tutorial written in Assembly.

Introducing a page of HLL Source never did that job.


> further you assume the user is working from a
> Windows environment which is another thing not guaranteed.

For sure, an Assembly programmer (learner) must be programming
(learning), under a given OS, as long as "portable Assembly"
does not really exist, even from OS to OS, other than with
over complicated and hidding things.


> Your
> example throws upon the hapless beginner the "push" and "call"
> instructions and before understanding what all this does, they need
> some background information on the memory subsystem and stack
> operation.  Things that require pages of reading to understand.

I did not posted a _Tutorial_. I posted a simple translation of
the HLL lines _you_ posted, in Assembly. Explaining what push, call,
stack, instructions,... are, is, very exactly, the job of a Tutorial,
and replacing these with HLL Statements, never was any explanation
about what Assembly is and does.

Now, all of this is _NOT_ my point. What I am pointing to, is the
serious problem that, an HLL that does not make the difference in
between what is Assembly is what is not, is not the proper tool
for learning Assembly, but, all the opposite, the proper tool for
introducing confusion about what is Assembly is what is not.

This seems to me pure logic: If you mean to learn Assembly, you need,
first, to _see_ where some Assembly is written, in a Tutorial.


Betov.

< http://rosasm.org >

On Jun 16, 3:04 am, Betov  <spamt...@crayne.org> wrote:
>
> > Which would only introduce confusions since none of these instructions
> > have yet been explained,
>
> Introducing and explaining instructions is one of the very true
> purpose of any Assembly Tutorial written in Assembly.

Indeed, but we are talking about the top-down vs. bottom up approach.
The top-down approach example I posted was taken from page 1 of the
tutorial and sets up the basic staging frame from which instructions
will be gradually introduced.
The bottom-up approach example you posted cannot be properly explained
on page one.  The aspiring student will first have to read through
material that covers the memory sub-system and an explanation of the
stack.


> Introducing a page of HLL Source never did that job.

Empirical evidence shows otherwise.

> > further you assume the user is working from a
> > Windows environment which is another thing not guaranteed.
>
> For sure, an Assembly programmer (learner) must be programming
> (learning), under a given OS, as long as "portable Assembly"
> does not really exist, even from OS to OS, other than with
> over complicated and hidding things.
>

The OS is not a necessary component for learning assembly and only
adds an extra layer in the process.  After all, the OS API is nothing
more than library calls.  HLA, AS, FASM, NASM and others have long
since proven that portable assembly does exist and with a portable
library access to the underlying OS, it offers a liberation rather
than a complication.

> > Your
> > example throws upon the hapless beginner the "push" and "call"
> > instructions and before understanding what all this does, they need
> > some background information on the memory subsystem and stack
> > operation.  Things that require pages of reading to understand.
>
> I did not posted a _Tutorial_. I posted a simple translation of
> the HLL lines _you_ posted, in Assembly. Explaining what push, call,
> stack, instructions,... are, is, very exactly, the job of a Tutorial,
> and replacing these with HLL Statements, never was any explanation
> about what Assembly is and does.
>

You posted a different approach which will have the same instructional
quality for everyone.  You prefer the bottom-up approach though what
you post is not strictly a bottom-up approach, but that's a moot
point.  Let's assume for the sake of argument that bottom-up starts
from the mnemonic instructions.  Your preference for that approach
works for you and that's fine.  For others, the top-down approach
works better.

> Now, all of this is _NOT_ my point. What I am pointing to, is the
> serious problem that, an HLL that does not make the difference in
> between what is Assembly is what is not, is not the proper tool
> for learning Assembly, but, all the opposite, the proper tool for
> introducing confusion about what is Assembly is what is not.
>

The distinction is trivial to comprehend for students bright enough to
be studying assembly.

> This seems to me pure logic: If you mean to learn Assembly, you need,
> first, to _see_ where some Assembly is written, in a Tutorial.
>
> Betov.
>
> <http://rosasm.org>

We both agree on this.  There are two distinctions to this argument.

1. What approach the tutorial takes.  The effectiveness of the two
approaches varies from person to person.  You claim the bottom-up
approach is the best for anyone but your argument fails as soon as one
person comes along and claims the top-down approach worked better for
them.  Well, I am at least one person who makes that claim.

I say both approaches have their merits.

2. When using an HLL, use one that makes a distinction of HLL vs.
assembly.

I say this is an irrelevant point.  It is better to choose a tool that
has the most quality pedagogy with the specific purpose of using the
tool to learn assembly.  In fact, this is the most important point no
matter which approach is used.

-sevag.k
www.geocities.com/kahlinor

I notice above, a usage of a style of ASM programming I have never
seen before this year, but apperently very common now and conceptually
quite understandable (examples above), loaded with pushes and calls.
This seems an acceptable method of using top-down concepts of building
a working program from tested sub-units (subroutines).

But sometime the ASM programmer has got to get down to writing these
sub-units that actually do the work required.

This is where ASM becomes different from, say, Fortran, where I still
do a lot of ASM unit calls in the same way as described above, and
with essentially the same stack usage.

But until you start moving bits into registers you are hardly
"programming in asm".

"sevag.krikorian"  <spamtrap@crayne.org> �crivait 
news:1182040857.870167.75620@n2g2000hse.googlegroups.com:

> Indeed, but we are talking about the top-down vs. bottom up approach.

No. Not at all. We (I, for sure) are talking about the fact that
an HLL, that makes no difference in between what is Assembly and
what is not, disqualifies itself as a tool for learning the basics
of Assembly.

If i have to recall you of this, HLA is introduced as a Tool
for learning/teaching Assembly, whereas it fully matches with
this remark: It makes no difference in between what is Asm and
what is not, and, if it means to mimic C, it should, at least,
propose some:

Asm {

      }

Now, whether the Bottom-Up or the Top-Down approach is best, is,
for now, matter of opinion, as long as no comparative study has
ever been conduct. Also, the efficiency of any pedagogical method,
for Assembly, does - hopefully - not reduce to the Bottom-Up vs
Top-Down ways dilemna. But there is one thing, which is 100% sure
and self-evident, that is that, if a beginner cannot _see_ what
is Asm, he is not in a context, where he could easily learn much
of it.


Betov.

< http://rosasm.org >

On Sat, 16 Jun 2007 23:24:33 -0700, Terence  <spamtrap@crayne.org>
wrote:

>I notice above, a usage of a style of ASM programming I have never
>seen before this year, but apperently very common now and conceptually
>quite understandable (examples above), loaded with pushes and calls.
>This seems an acceptable method of using top-down concepts of building
>a working program from tested sub-units (subroutines).

The pushes and calls you refer to are simply a way to invoke Win32 API
calls from assembly.  MASM32 allows you to hide all this with the
INVOKE format, which looks more like HLL.  So instead of
   push Param2
   push Param1
   call SomeAPIfunct

you use
   invoke SomeAPIfunct, Param1, Param2

I like this approach because it keeps the API invocation stuff
neatly grouped and separated from the rest of the code.

Best regards,



Bob Masta
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
           www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
    Science with your sound card!

NoSpam@daqarta.com (Bob Masta) �crivait news:467506d8.384437
@news.sysmatrix.net:

> The pushes and calls you refer to are simply a way to invoke Win32 API
> calls from assembly.  MASM32 allows you to hide all this with the
> INVOKE format, which looks more like HLL.  So instead of
>    push Param2
>    push Param1
>    call SomeAPIfunct
> 
> you use
>    invoke SomeAPIfunct, Param1, Param2
> 
> I like this approach because it keeps the API invocation stuff
> neatly grouped and separated from the rest of the code.

Right. Though, all Assemblers around can do this, through user
defined Macros. RosAsm:

    call 'DLL.function', Param1, Param2

That being said, the level of HLLisms, enabled by an Assembler's
Macros System, is out of scope of this thread, and for learning
the Assembly basics, a Tutorial should keep with the flat Asm
notations. If not, the problem would be similar to the one
introduced by HLA, that is, that, instead of having to learn
one another HLL, in the illusive hope of finaly accessing to
the beautiful simplicity of Assembly, the learner would also
have to first learn a Macros System for doing the same thing.
A bit better, as long as, at least, learning a Macros System
is never completely useless, but, nervertheless, a curtain of
formalism in between the learner's eyes and pure Assembly.

One another example about why and how an Assembly Tutorial,
based on HLL (or, here, HLLisms), should always make a clear
difference in between what is HLL and what is Asm.


Betov.

< http://rosasm.org >

On Jun 17, 3:00 am, Betov  <spamt...@crayne.org> wrote:
> "sevag.krikorian"  <spamt...@crayne.org> �crivaitnews:1182040857.870167.75620@n2g2000hse.googlegroups.com:
>
> > Indeed, but we are talking about the top-down vs. bottom up approach.
>
> No. Not at all. We (I, for sure) are talking about the fact that
> an HLL, that makes no difference in between what is Assembly and
> what is not, disqualifies itself as a tool for learning the basics
> of Assembly.

According to your first post in this thread, that was the second
paragraph.  The first paragraph you did make a comment about the top-
down approach and so the scope of this discussion also includes top-
down vs bottom-up.

>
> If i have to recall you of this, HLA is introduced as a Tool
> for learning/teaching Assembly, whereas it fully matches with
> this remark: It makes no difference in between what is Asm and
> what is not, and, if it means to mimic C, it should, at least,
> propose some:
>
> Asm {
>
>       }
>

Again, I believe this is not a significant factor of the tool.  As
assembly concepts are introduced, it is easy enough to tell them apart
from their HLL counterparts, in the same way someone coming from the
bottom-up can tell the difference between assembly concepts and HLL
macro concepts introduced later.

I may have more consideration for your argument if you are willing to
concede that assemblers that use macros should have a clear
distinction between what is asm and what is macro:

Macro {
  call 'DLL.function', Param1, Param2
}

> Now, whether the Bottom-Up or the Top-Down approach is best, is,
> for now, matter of opinion, as long as no comparative study has
> ever been conduct.

Agreed.  But we do know that both methods have proven effective for
some students.  The problem I see is the availability of quality
material for the bottom-up approach.  The few books I've seen (those
available for free) that use a bottom-up approach aren't put together
very well... they go on and on before any experimental code can be
written by the student.  The only one to come close is Bartlett's book
which offers the first assembly program on chapter 3, but that
tutorial suffers from use of AT&T syntax, which IMO, is not a very
good syntax for beginners (or anybody for that matter!).


> Also, the efficiency of any pedagogical method,
> for Assembly, does - hopefully - not reduce to the Bottom-Up vs
> Top-Down ways dilemna.

Also agreed.  The pedagogical material should pick one method and
stick with it throughout the course.

> But there is one thing, which is 100% sure
> and self-evident, that is that, if a beginner cannot _see_ what
> is Asm, he is not in a context, where he could easily learn much
> of it.
>
> Betov.
>
> <http://rosasm.org>

The beginner can easily see which parts are HLL and which are
assembly.  It is being taught as the student reads through the
pedagogy.  I had no trouble in the distinction as I went through HLA.


-sevag.k
www.geocities.com/kahlinor

On 17 Jun 2007 12:13:39 GMT, Betov  <spamtrap@crayne.org> wrote:

>NoSpam@daqarta.com (Bob Masta) �crivait news:467506d8.384437
>@news.sysmatrix.net:
>
>> The pushes and calls you refer to are simply a way to invoke Win32 API
>> calls from assembly.  MASM32 allows you to hide all this with the
>> INVOKE format, which looks more like HLL.  So instead of
>>    push Param2
>>    push Param1
>>    call SomeAPIfunct
>> 
>> you use
>>    invoke SomeAPIfunct, Param1, Param2
>> 
>> I like this approach because it keeps the API invocation stuff
>> neatly grouped and separated from the rest of the code.
>
>Right. Though, all Assemblers around can do this, through user
>defined Macros. RosAsm:
>
>    call 'DLL.function', Param1, Param2
>
>That being said, the level of HLLisms, enabled by an Assembler's
>Macros System, is out of scope of this thread, and for learning
>the Assembly basics, a Tutorial should keep with the flat Asm
>notations. If not, the problem would be similar to the one
>introduced by HLA, that is, that, instead of having to learn
>one another HLL, in the illusive hope of finaly accessing to
>the beautiful simplicity of Assembly, the learner would also
>have to first learn a Macros System for doing the same thing.
>A bit better, as long as, at least, learning a Macros System
>is never completely useless, but, nervertheless, a curtain of
>formalism in between the learner's eyes and pure Assembly.

Actually, I agree with you on this in general.  I almost never
use macros of any other sort; but INVOKE actually helps
isolate the beautiful simplicity of assembly from the
unavoidable API stuff.  I'd strongly recommend it to a student 
to remove the API clutter and concentrate on his own
assembly code.   This also reduces the chance of confusing
the string of PUSHes needed by the API from those you want
in your own code (such as saving registers that you know the
API will trash).

Best regards,



Bob Masta
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
           www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
    Science with your sound card!

Hi,

IMHO the best way to learn assembly is to forget about any kind of
programming to begin with, and learn how computers actually work -
what memory is, what CPUs do, what registers are, how a stack works,
etc. Then learn about numbers - how they're stored, different bases
(binary, hex, etc). Only worry about how to program after these things
are understood.

Then you want an emulator, but not just a normal emulator - a
graphical tool that displays the contents of registers, the stack and
RAM, and shows (step by step) the effect that the student's
instructions have. The problem is that tools like this don't really
exist anymore (they used to - it's how I learnt 6502 assembly when I
was a kid).

Using a high level language to teach assembly is like using a boat to
teach people how to drive a car - it simply doesn't make any sense
(unless you're secretly trying to sell boats).


Cheers,

Brendan

"Bob Masta" <NoSpam@daqarta.com> wrote in message 
news:467688e5.9302378@news.sysmatrix.net...

> Actually, I agree with you on this in general.  I almost never
> use macros of any other sort; but INVOKE actually helps
> isolate the beautiful simplicity of assembly from the
> unavoidable API stuff.  I'd strongly recommend it to a student
> to remove the API clutter and concentrate on his own
> assembly code.   This also reduces the chance of confusing
> the string of PUSHes needed by the API from those you want
> in your own code (such as saving registers that you know the
> API will trash).

I typically think of you as a sensible guy, Bob, which is makes
it more difficult to comprehend why you would recommend INVOKE.
Consider that (in Windows x64) immediately before the CALL
instruction, the stack must be aligned to a multiple of 16
bytes and that the 32 bytes at top of stack must be available
to the callee as a parameter save area.  If the assembler is
not sure about stack alignment before the INVOKE macro, it
must generate code to align the stack at every invocation.
In that case it would also have to create the 32 byte area
unilaterally.

If the assembler doesn't know where the scratch space in the
stack frame is, it would have to PUSH caller-save registers
and any arguments past the fourth, rather than use simpler
MOV instructions.

If the assembler does know all of the above stuff, that means
it has to have complete control over the stack frame at all
times, which makes any procedure look more like it written in
HLL rather than ASM.  When you you INVOKE, you have to know
which of the alternatives is in force so that you have to
keep track of HLL abstractions rather than concentrate on the
object of the exercise which should have been to write good
clean low-level code from the start.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Brendan  <spamtrap@crayne.org> �crivait news:1182181507.184833.305070
@e9g2000prf.googlegroups.com:

> Then you want an emulator, but not just a normal emulator - a
> graphical tool that displays the contents of registers, the stack and
> RAM, and shows (step by step) the effect that the student's
> instructions have. The problem is that tools like this don't really
> exist anymore (they used to - it's how I learnt 6502 assembly when I
> was a kid).

The real reason why i started this thread, is exactly because
the RosAsm team has developed something like this. RosAsm menu:
[Help]/[Visual Tuts] ---> Twelve Assembly Lessons.

We are actually finishing the proof-readings, but the actual
version, as included inside 'RosAsmFull.zip', should be very
close to its final state.

I will promote this method before we start the national languages
translations... Soon.


> Using a high level language to teach assembly is like using a boat to
> teach people how to drive a car - it simply doesn't make any sense
> (unless you're secretly trying to sell boats).

Sure. What stucks me is that people could believe otherwise.
All Asmers know that there is a _HUGE_ difference in between
Inline Assembly and developments of Applications in Assembly.

But, in this thread, i was just pointing out that, because it
does not even make any difference from HLL to Inline Assembly,
HLA disqualifies as an Asm learning Tool. Even C would do better,
in my opinion, at this point of view, with Inline Asm.


Betov.

< http://rosasm.org >

James Van Buskirk <spamtrap@crayne.org> wrote in part:
> I typically think of you as a sensible guy, Bob, which is makes
> it more difficult to comprehend why you would recommend INVOKE.

I'm not Bob, but I thought this was in an instructional
context, not high-performance production code.

> Consider that (in Windows x64) immediately before the CALL
> instruction, the stack must be aligned to a multiple of 16 bytes
> and that the 32 bytes at top of stack must be available to the
> callee as a parameter save area.  If the assembler is not sure
> about stack alignment before the INVOKE macro, it must generate
> code to align the stack at every invocation.  In that case it
> would also have to create the 32 byte area unilaterally.

And this is so horrid?  Any syscall is expected to be slow.
The Ring3 -> Ring0 transition takes considerable time (100s
of clocks).  The I/O almost always involved is much worse.

The key to syscalls is reducing their number or putting
them in a parallel thread.  Why micro-optimize the elephant?

-- Robert

On Jun 18, 11:05 am, Betov  <spamt...@crayne.org> wrote:
>
> The real reason why i started this thread, is exactly because
> the RosAsm team has developed something like this. RosAsm menu:
> [Help]/[Visual Tuts] ---> Twelve Assembly Lessons.

It is interesting how you feel the need to attack other products in
order to promote your own.

>
> We are actually finishing the proof-readings, but the actual
> version, as included inside 'RosAsmFull.zip', should be very
> close to its final state.

We are all looking forward to this :-)


>
> I will promote this method before we start the national languages
> translations... Soon.
>
> > Using a high level language to teach assembly is like using a boat to
> > teach people how to drive a car - it simply doesn't make any sense
> > (unless you're secretly trying to sell boats).
>
> Sure. What stucks me is that people could believe otherwise.

That should tell you something.

> All Asmers know that there is a _HUGE_ difference in between
> Inline Assembly and developments of Applications in Assembly.

So who is teaching assembly language programming using in-line
assembly constructs? Please share the link. There are some people out
there who actually want to learn assembly this way and I've never seen
a practical tutorial that teaches assembly language in this manner. If
you've got some pointers at educational material that does this,
please share it with us so I can point people who are so interested in
that direction.


>
> But, in this thread, i was just pointing out that, because it
> does not even make any difference from HLL to Inline Assembly,
> HLA disqualifies as an Asm learning Tool.

I guess the same could be said about MASM and TASM, eh? Are you saying
that MASM and TASM are disqualified as assembly language learning
tools? That would be amusing, considering that *most* people who've
learned x86 assembly language programming have learned it using one of
those two tools.

> Even C would do better,
> in my opinion, at this point of view, with Inline Asm.

You are welcome to your opinions, but in the real world beginners who
get to choose their instructional method tend not to take your
approach.

Good luck with your tutorials. I've reviewed a couple of them and I
believe you're going to be disappointed at the reception they get from
actual beginners. But it's a good first step. Once you discover the
problems beginners have with your tutorials, I hope that you work on
correcting the problems. Maybe when your tutorials have been around as
long as the "Art of Assembly Language" they will be as refined.
hLater,
Randy Hyde

On Jun 15, 12:39 am, Betov  <spamt...@crayne.org> wrote:

>
> Right. And this is part of what i am pointing to:
>
> > program helloWorld;
> > #include ("stdlib.hhf")
>
> > begin helloWorld;
>
> >      stdout.put ("Hello, World of Assembly Language", nl);
>
> > end helloWorld;
>
> Right: This is plain HLL,

Not by anything you've ever said in the past.
You've always maintained that if someone invokes a *macro* they are
writing *real assembly language*. Guess what? stdout.put is a *macro*.
It expands to a push and a call. You don't seem to have a problem
calling the following assembly language:

call "somekernelfunction", parameter1, parameter2

Other than trivial syntax, explain the difference between the RosAsm
statement immediately above and the HLA standard library stdout.put
macro.

Unless you're willing to label *all* macro assemblers (including your
own) "high-level languages", I'm afraid you don't get to call the
above program a "HLL program."
hLater,
Randy Hyde

On Jun 18, 8:45 am, Brendan  <spamt...@crayne.org> wrote:
> Hi,
>
> IMHO the best way to learn assembly is to forget about any kind of
> programming to begin with,

"Best" by what metric?
Generally, forgetting knowledge that you could leverage in the current
phase of your education is an inefficient way to proceed. Most people
prefer to build their knowledge up on the information they already
possess.

> and learn how computers actually work -
> what memory is, what CPUs do, what registers are, how a stack works,
> etc. Then learn about numbers - how they're stored, different bases
> (binary, hex, etc).

Have you actually read the book whose pedagogy Rene is criticizing(The
Art of Assembly Language)? Are you not aware of the fact that the book
presents this material in much the same order you're suggesting?


> Only worry about how to program after these things
> are understood.

That would be great if someone has all the time in the world to learn
the subject. However, mastery of those subjects you've listed in a
real-world University setting takes several weeks. If the school has a
10-week quarter system, you've just burned up about 30% of the course
time with no programming taking place. If the course is "Assembly
Language PROGRAMMING", it's a real shame to spend 3 weeks or so on the
prerequisite material before *any* programming takes place. Better to
start teaching the student trivial things they can do in assembly
language to get them started rather than put off all the programming
until this material is covered.

The "Hello World" program, for example, doesn't exist as a mechanism
for teaching "assembly language" per se, that example exists (for the
same reason it appeared in "The C Programming Language") in order to
get the student comfortable using a text editor, a command-line
compiler, executing the result from a command line, etc.  Seemingly
trivial, but a step that every beginner has to go through. And no, you
cannot simply assume the student already knows how to do all that
stuff.


>
> Then you want an emulator, but not just a normal emulator - a
> graphical tool that displays the contents of registers, the stack and
> RAM, and shows (step by step) the effect that the student's
> instructions have. The problem is that tools like this don't really
> exist anymore (they used to - it's how I learnt 6502 assembly when I
> was a kid).

Those types of tools are fantastic for learning how individual
instructions operate. They aren't really practical tools for learning
*programming*. And any decent debugger (e.g., OllyDbg) does everything
you're asking for except for the pretty pictures.  OTOH, do keep in
mind that using such a tool requires a bit of expertise and students
have to be trained how to use it. This robs valuable time (learning
the program) that could be put to better use learning assembly
language. When you were a kid using the 6502, efficient use of your
time wasn't important. When you're taking a course and you're only
allotted 12 hours/week for lectures, labs, and course work, every
minute counts.


>
> Using a high level language to teach assembly is like using a boat to
> teach people how to drive a car - it simply doesn't make any sense
> (unless you're secretly trying to sell boats).

You make this pronouncement after looking at *one* assembly language
macro in HLA? Hmmmm....
You do realize that I can produce a comparable macro for just about
every other assembler out there, right?

Now if you have a problem with using macros to hide the low-level
details of an OS call, just keep in mind that learning those low-level
calls have *nothing* to do with learning assembly language
instructions. Worse, the complexity of those calls means that you will
not be able to have the students write a meaningful "Hello World"
style program until several weeks into the course (unless you spoon-
feed them the code, which is worthless).

If you've got all the time in the world and you don't care how quickly
you master the subject, you can certainly learn assembly language by
hacking away at it; but most people (students or otherwise) value
their time and are a little annoyed when they are forced to learn a
subject in an inefficient manner.
hLater,
Randy Hyde

On Jun 18, 7:21 pm, "r...@cs.ucr.edu"  <spamt...@crayne.org> wrote:
> On Jun 18, 11:05 am, Betov  <spamt...@crayne.org> wrote:

>
> Good luck with your tutorials. I've reviewed a couple of them and I
> believe you're going to be disappointed at the reception they get from
> actual beginners. But it's a good first step. Once you discover the
> problems beginners have with your tutorials, I hope that you work on
> correcting the problems. Maybe when your tutorials have been around as
> long as the "Art of Assembly Language" they will be as refined.
> hLater,
> Randy Hyde

I predict what will happen is that whoever cannot learn assembly with
Betov's tutorials will be insulted by being told they are not smart
enough to learn assembly.

-sevag.k
www.geocities.com/kahlinor

On Jun 18, 7:40 pm, "r...@cs.ucr.edu"  <spamt...@crayne.org> wrote:
> On Jun 18, 8:45 am, Brendan  <spamt...@crayne.org> wrote:
>
> > Hi,
>
> > IMHO the best way to learn assembly is to forget about any kind of
> > programming to begin with,
>
> "Best" by what metric?
> Generally, forgetting knowledge that you could leverage in the current
> phase of your education is an inefficient way to proceed. Most people
> prefer to build their knowledge up on the information they already
> possess.
>
> > and learn how computers actually work -
> > what memory is, what CPUs do, what registers are, how a stack works,
> > etc. Then learn about numbers - how they're stored, different bases
> > (binary, hex, etc).
>
> Have you actually read the book whose pedagogy Rene is criticizing(The
> Art of Assembly Language)? Are you not aware of the fact that the book
> presents this material in much the same order you're suggesting?
>
> > Only worry about how to program after these things
> > are understood.
>
> That would be great if someone has all the time in the world to learn
> the subject. However, mastery of those subjects you've listed in a
> real-world University setting takes several weeks. If the school has a
> 10-week quarter system, you've just burned up about 30% of the course
> time with no programming taking place. If the course is "Assembly
> Language PROGRAMMING", it's a real shame to spend 3 weeks or so on the
> prerequisite material before *any* programming takes place. Better to
> start teaching the student trivial things they can do in assembly
> language to get them started rather than put off all the programming
> until this material is covered.
>
> Randy Hyde

The problem with me, and I believe I'm not alone in this, is that if I
have to absorb multiple concepts before theory can be put to practice,
my mind begins to wonder and I enter a state of what I call "blank
reading" which is just reading the words without digesting anything
and I miss important concepts.

As an example back from my high school days, one chapter in math
introduced several concepts and then exercise problems at the end of
the chapter.  I had much difficulty with those until I changed my
study habits by reading one concept, doing the problems associated
with that concept, going back to read another concept, doing the
problems, etc.

The reason AoA has high regards with me is due to that approach being
default.  It follows the pattern of introducing a concept and putting
the theory into practice right away.  You can experiment with it, it
keeps you interested and best of all, you learn by doing.  In some
places, it's even hard to go five pages without seeing example code.
At no time was I ever faced with a concept that wasn't previously
explained.

-sevag.k
www.geocities.com/kahlinor

"rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait 
news:1182209270.578010.278280@a26g2000pre.googlegroups.com:

> You've always maintained that if someone invokes a *macro* they are
> writing *real assembly language*.

What i have always maintained is that "User Defined Macros",
in the context of a Macros Assembler, is still... "Macros-
Assembly".

What i have pushed the RosAsm's user to do, is to make use
of a reasonable usage of Macros, because, as all Asmers who
created Applications in full Assembly know from experience,
above some size and some level of complexity, maintaining
a Source in flat Assembly may becomes difficult.

Here, we are not talking about creating Applications in full
Assembly, but about how decent Assembly tutorials should be
written, and, as already said, it is self-evident that this
kind of material should keep with flat Assembly in order to
not overload the learner with a too heavy charge.

It is also self-evident that an HLL not making any difference
in between what is HLL, and what is inline Assembly, is not
the appropriate tool for learning Assembly.


Betov.

< http://rosasm.org >

"rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait 
news:1182208906.136420.318520@i13g2000prf.googlegroups.com:

> It is interesting how you feel the need to attack other products in
> order to promote your own.

When developping Tutorials, it is always interresting to take
a look at what the other Tutorials have to propose. I have to
say that, the way you took, was an example, for me, of what i
should not do.

In some way, The Twelve Assembly Tutorials are just the reverse
of your materials:

Short ---> Long
Bottom-Up ---> Top-Down
Generic Syntax ---> Home made one, that no Assembler around uses
HLL-based ---> Flat Assembly
.... and so on...

So, yes, these two kinds of approaches will evidently confront.


Betov.

< http://rosasm.org >

"Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message 
news:B7Bdi.2039$vi5.177@newssvr17.news.prodigy.net...

> James Van Buskirk <spamtrap@crayne.org> wrote in part:

> I'm not Bob, but I thought this was in an instructional
> context, not high-performance production code.

Exactly.  My comment wasn't about generating high-performance
code, although I think such code is a good thing, but about
getting code that works, especially regarding the issue of
interfacing between procedures.

>> Consider that (in Windows x64) immediately before the CALL
>> instruction, the stack must be aligned to a multiple of 16 bytes
>> and that the 32 bytes at top of stack must be available to the
>> callee as a parameter save area.  If the assembler is not sure
>> about stack alignment before the INVOKE macro, it must generate
>> code to align the stack at every invocation.  In that case it
>> would also have to create the 32 byte area unilaterally.

> And this is so horrid?  Any syscall is expected to be slow.
> The Ring3 -> Ring0 transition takes considerable time (100s
> of clocks).  The I/O almost always involved is much worse.

> The key to syscalls is reducing their number or putting
> them in a parallel thread.  Why micro-optimize the elephant?

Again, the issue is not at all about optimization, but about
code that at least performs its basic function.  There is one
calling convention in 'doze x64, and procedures we write
should normally conform to it. Certainly procedures generated
by any compiler or any of our procedures we hope to interface
to compiled code must do so. This seems to make a lot of
sense for procedures we wish to share with others as well.
Thus it's not about syscalls, but pretty much all procedures.

Given the 'doze x64 calling convention it doesn't make any
sense to push arguments on the stack and then issue the
CALL instruction, because the callee won't be looking for the
first four arguments on the stack and will also be assuming
the stack is aligned. At one extreme the INVOKE macro could
save the old rsp, AND rsp with 0fffffffffffffff0h, push
caller-save registers, subtract 8 from rsp if necessary,
push arguments after the fourth, copy the first four
arguments to rcx, rdx, r8, r9, or xmm0, xmm1, xmm2, xmm3 as
the case may be, issue the CALL instruction, add the
appropriate amount to rsp, pop caller-save registers, and
restore old rsp.

In a RISC environment, such as AlphaNT as I am accustomed to,
one would already have set up the caller's stack frame such
that the stack pointer pointed where we would want it to
at the time the caller would issue the CALL instruction.
Thus caller-save registers would be placed in the stack frame
via store instructions, as would procedure arguments beyond
IIRC the first 6, the CALL instruction would be issued, and
afterwards there would be nothing to clean up because we
like the stack frame in the state it finds itself in. Of
course we may wish to restore some caller-save registers via
load instructions at this time, but we need not be in a hurry
because we might just be making another procedure invocation
right away.

We can see that at the other extreme, it might be logical
for the assembler to assume that there is space to save all
the caller-save registers that it knows (perhaps because we
tell it so in the INVOKE macro) that we still will be
interested in preserving across the procedure call. Also it
might assume that there is the right amount of space for
arguments past the fourth and the 32-byte argument save area
and the the stack will be properly aligned at that point of
the INVOKE macro.  This is not a question of optimization,
but rather of programming style because Alphas don't have
PUSH and POP instructions.

There are many possibilities between these extremes and logic
will not permit us to deduce the exact meaning of the INVOKE
macro: we must know it for every assembler we use (FASM, GoAsm,
ml64, or YASM, perhaps others will be added to the list of
x64 assemblers but these four are all we have today) and not
get them confused with one another.  If you don't write code
with the same assembler every day, you are going to have to
look up the details, perhaps in marginal documentation, of
what the INVOKE macro does every time you use it.  For me,
it's much simpler to just write out the instruction sequence
that the INVOKE macro would have replaced, perhaps with a
comment or two interspersed.  Teaching a beginner that the
INVOKE macro does something specific would seem to me to only
lead to confusion.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On Mon, 18 Jun 2007 11:41:51 -0600, "James Van Buskirk"
<spamtrap@crayne.org> wrote:

>"Bob Masta" <NoSpam@daqarta.com> wrote in message 
>news:467688e5.9302378@news.sysmatrix.net...
>
>> Actually, I agree with you on this in general.  I almost never
>> use macros of any other sort; but INVOKE actually helps
>> isolate the beautiful simplicity of assembly from the
>> unavoidable API stuff.  I'd strongly recommend it to a student
>> to remove the API clutter and concentrate on his own
>> assembly code.   This also reduces the chance of confusing
>> the string of PUSHes needed by the API from those you want
>> in your own code (such as saving registers that you know the
>> API will trash).
>
>I typically think of you as a sensible guy, Bob, which is makes
>it more difficult to comprehend why you would recommend INVOKE.
>Consider that (in Windows x64) immediately before the CALL
>instruction, the stack must be aligned to a multiple of 16
>bytes and that the 32 bytes at top of stack must be available
>to the callee as a parameter save area.  If the assembler is
>not sure about stack alignment before the INVOKE macro, it
>must generate code to align the stack at every invocation.
>In that case it would also have to create the 32 byte area
>unilaterally.
>
>If the assembler doesn't know where the scratch space in the
>stack frame is, it would have to PUSH caller-save registers
>and any arguments past the fourth, rather than use simpler
>MOV instructions.
>
>If the assembler does know all of the above stuff, that means
>it has to have complete control over the stack frame at all
>times, which makes any procedure look more like it written in
>HLL rather than ASM.  When you you INVOKE, you have to know
>which of the alternatives is in force so that you have to
>keep track of HLL abstractions rather than concentrate on the
>object of the exercise which should have been to write good
>clean low-level code from the start.
>

First of all, I have never done any x64 coding, and x32 doesn't
seem to need any special handling.  

However, even considering the x64 situation you mention, I fail to see
any problem with INVOKE.   In x32 at least, INVOKE does nothing
more than push the specified data in the required order for the call.
I surely hope that the same is true in x64, and that any special
pre-manipulation of the stack is entirely up to you... the assembler
doesn't have complete control of anything.  This makes the argument
for INVOKE even stronger, IMHO, since it isolates the purely
"mechanical"  pushes from any special handling that may be
required.   By putting the API stuff all on one line of code, you
can clearly distinguish API code from everything else, including
special set-up code, if needed.

Best regards,


Bob Masta
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
           www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
    Science with your sound card!

On Jun 19, 12:43 am, "James Van Buskirk"  <spamt...@crayne.org> wrote:
>
> There are many possibilities between these extremes and logic
> will not permit us to deduce the exact meaning of the INVOKE
> macro:

Well, you *could* try reading the documentation. INVOKE (at least, on
the x86-64) is MASM-specific. Somewhere, I suspect, Microsoft has
documented its exact behavior. If the default behavior doesn't always
produce correct results (inefficient or otherwise), I would suggest
that it is broken. A beginner should be able to use it without
understanding what's going on behind the scenes, an advanced
programmer should be able to use it knowing *exactly* what code it
generates, choosing to use explicit code if INVOKE doesn't do exactly
what they want.

BTW, a while back I'd heard that INVOKE was broken (in MASM) on the
x86-64, has this been fixed?

> we must know it for every assembler we use (FASM, GoAsm,
> ml64, or YASM, perhaps others will be added to the list of
> x64 assemblers but these four are all we have today) and not
> get them confused with one another.  

Well, yes, just like any other feature that isn't the same across all
the assemblers you choose to use. This is why most people stick with
one assembler as much as possible -- it's less to keep track of.

BTW, I'm still under the impression that INVOKE is basically a MASM
feature. I've seen people *try* to create INVOKE macros for other
assemblers, but they vary in their quality. Generally, when people
speak of INVOKE, however, they are talking about MASM.

> If you don't write code
> with the same assembler every day, you are going to have to
> look up the details, perhaps in marginal documentation, of
> what the INVOKE macro does every time you use it.  

Yes, that is the price you pay for using all these different
assemblers. Assuming, of course, that they all have some sort of
INVOKE statement. I wasn't aware this was the case.

> For me,
> it's much simpler to just write out the instruction sequence
> that the INVOKE macro would have replaced, perhaps with a
> comment or two interspersed.  

Works great until you accidentally leave off a parameter or pass the
wrong type. The *real* INVOKE statement in MASM (and the HLL-like
procedure call in HLA) checks the parameters (count and type). That's
*really* handy and has caught a lot of errors I've made over the
years. Further, if you ever change the parameter list, a recompile
will turn up all the locations where the parameter list doesn't match.
That's an incredibly nice feature you don't get when you manually pass
the parameters to a procedure.


> Teaching a beginner that the
> INVOKE macro does something specific would seem to me to only
> lead to confusion.

Well, I can't speak for INVOKE, as I quit using MASM to teach assembly
language before introducing INVOKE, but I can state that if you use a
HLL-like procedure call that automatically handles parameters for the
student, they can apply knowledge from their HLL programming courses
and they immediately understand how to make some (otherwise)
sophisticated procedure calls. That is, they can call procedures and
pass parameters without having to know what a push instruction is, for
example (or, God help them, stack alignment issues like those being
discussed here). Sure, sooner or later they need to learn about this
stuff, but early in the course it's just confusing. Better to let them
use a syntax that is reminiscent of their HLLs.
hLater,
Randy Hyde

James Van Buskirk <spamtrap@crayne.org> wrote in part:
> Exactly.  My comment wasn't about generating high-performance
> code, although I think such code is a good thing, but about
> getting code that works, especially regarding the issue of
> interfacing between procedures.

For pure teaching, perhaps using libc calls rather than
syscalls is both more familiar and simpler.

"Bare metal" or "Direct to OS" isn't the only kind of ASM.
An argument can be made that such "Systems Programming"
is a totally different subject from learning Assembly.

> At one extreme the INVOKE macro could save the old rsp,
> AND rsp with 0fffffffffffffff0h, push caller-save registers,
> subtract 8 from rsp if necessary, push arguments after the
> fourth, copy the first four arguments to rcx, rdx, r8,
> r9, or xmm0, xmm1, xmm2, xmm3 as the case may be, issue
> the CALL instruction, add the appropriate amount to rsp,
> pop caller-save registers, and restore old rsp.

If MS-Win64 requires alignment and the assembler doesn't
generate/track it, then what other way could INVOKE work?
Require alignment at INVOKE and let the OS barf if the pgmr forgot?

> In a RISC environment, such as AlphaNT as I am accustomed
> to, one would already have set up the caller's stack frame

Sure.  But that requires you to have a fairly intimate
knowledge of the structure of that frame.  INVOKE tries
to reduce [hide] those requirements.

> If you don't write code with the same assembler every day,
> you are going to have to look up the details, perhaps in
> marginal documentation, of what the INVOKE macro does every
> time you use it.  For me, it's much simpler to just write
> out the instruction sequence that the INVOKE macro would
> have replaced, perhaps with a comment or two interspersed.
> Teaching a beginner that the INVOKE macro does something
> specific would seem to me to only lead to confusion.

I would personally agree.  But I find MS-Win32 already
obscured, passing though [a series of?] callgates rather than
a simple `int 0x80` interface.  Apparently MS wants _lots_
of flexibility in the syscalls they provide.  Why write code
for such a shifty base?  Then I fall back to LIBC.

-- Robert