On Oct 27, 9:11 am, Frank Kotler
<
fbkot...@nospicedham.myfairpoint.net> wrote:
> cmp eax, ebx "ok" (to use your example)
> jz L1 "???"
>
> If "L1" has been "seen", fine. If it's a forward reference... put in a
> placeholder? Will a "short" jump fit, or will we need "near"? We may
> need to relocate any following code, once we find out where "L1" is. In
> this case, is it still "incremental"? I dunno.
Well, I tried this out in SwiftForth:
code flag ( n -- flag ) ok
ebx ebx or 0<> if -1 # ebx mov then ok
ret end-code ok
9 flag . -1 ok
0 flag . 0 ok
see flag
46E89F EBX EBX OR 09DB
46E8A1 46E8A8 JZ 7405
46E8A3 -1 # EBX MOV BBFFFFFFFF
46E8A8 RET C3 ok
SwiftForth seems to just be using short jumps by default. I don't know
what would happen if your function was so big that it required a near
jump; maybe get an error message. If I was writing the assembler, I
would be fine with this being an error. When I wrote my 65c02 Forth
and assembler, I required forward jumps to be short and only in a very
few cases was this a problem, but I just factored the function rather
than "fix" the assembler. Another option when this error cropped up,
would be to switch to inline assembly and manually code a far jump (my
Forth wasn't standard anyway, so the occasional use of inline-assembly
wasn't a problem). For backward jumps my compiler was smart enough to
use either a short or a far jump as necessary.
This issue has never been important to me. In Forth, programmers are
strongly urged to factor the heck out of their programs. We don't
generally have lengthy functions; we have a lot of very short
functions. Forth allows interactive testing, so it makes sense to have
short functions that do only one thing and which do not access global
data but whose results are entirely dependent upon the input
parameters. It is possible to test each function by trying it out with
some input parameters (a few typical parameters, the edge cases and
the illegal parameters), and then you are reasonably confident that
your function is good and you don't have to worry about it anymore.
I have seen both C and traditional assembly programs in which the
functions were gigantic. A lot of such programmers will give lip
service to the idea of factoring a program into small functions, but
they don't do this in practice. They can't interactively test their
functions at the console, so having small functions doesn't benefit
them. They run their entire program through a debugger and step
through their code, so it doesn't really matter if the code is
organized as a few big functions or a lot of small functions. The only
advantage of small functions is that they make for handy breakpoint
targets, and it is possible to step over a function call rather than
step through all the code in the function, but neither of these
advantages are apparently important enough to induce the C and
traditional assembly programmers to factor their programs --- because
I never see them do it!
I hate debuggers! I haven't used a debugger or an ICE this century,
and I don't plan on doing so again in my lifetime. I'm really enamored
to functional-programming, in which small functions are stand-alone
and can be tested interactively. In my 65c02 Forth I provided source-
level debugging; I could single-step through programs, step over
function calls, set breakpoints, etc.. I wrote that 20 years ago
though. I know more about programming now, and I no longer have any
need for that kind of thing.
> So Luxasm and RosAsm are, for practical purposes, "dead". If Betov is
> still alive, he'll be angry to see RosAsm and HLA mentioned on the same
> page (same universe!). If not, he'll be rolling over in his grave. Tough!
I did notice that RosAsm and HLA seem to be very different, and might
have difficulty coexisting in the same universe. HLA is all about the
macro language, and RosAsm is all about simplicity in the sense of
eschewing macros. I think that I'm a lot more on the HLA side of the
fence, which is another reason why I didn't feel inspired to
investigate RosAsm further.
> My "objection" to HLA is that I feel that teaching a beginner
> "stdout.puts("hello, world");" and claiming that you're teaching them
> "assembly language" is... "misleading" (nicest word I can think of).
Realistically, how many beginning programmers (or advanced
programmers, for that matter), are going to write their own console
interface code? Not me! I want to get my program completed before the
end of the century, so I don't want to spend a lot of time on low-
level stuff like this --- I'm happy to let somebody else do that for
me --- if Randy Hyde and his students are volunteering to provide that
stuff for free, then I'll take it.
I think that HLA and its macros are great. I also think that Forth and
its compile-time code is great. I also remain unemployed...
I have worked as a programmer in the past. I was often told that my
code had to look just like everybody else's code. The goal was that,
if I got run over by a bus while walking to work, the company could
hire another programmer who could sit down at my desk and look at my
code and immediately understand it and begin working on it. What this
means essentially, is that I can't use macros. That other programmer
doesn't want to look at my code and see a macro being used, and not
know what it does --- he just wants to see MOV and LEA and so forth,
that he is familiar with. This is why Forth is not used commercially
--- because Forthers use a lot of macros (immediate words) --- one
Forth program doesn't look very much like another Forth program, as
the language has been made to fit the application. By comparison, C
doesn't have macros (except for #define which is so simplistic that it
doesn't really count), so all C programs look alike.
I have worked as an assembly language programmer. My experience is
that the company typically has an approved library of macros that were
written by some genius (the boss describes himself as such), but the
ordinary programmers (me) are strongly discouraged from writing macros
of their own. The rational is that they aren't smart enough to write
macros, and that doing so is outside of their paygrade. The real
reason is what I described above, in regard to what will happen if the
programmer gets run over by a bus (or, more likely, annoys the boss
and gets fired).
I like macros though! As for getting run over by a bus, I avoid that
by looking both ways before crossing the street. As for annoying the
boss, that can also be avoided. Whenever the boss begins talking, the
best thing to do is shut one's mouth, grin like an idiot, and bob
one's head up and down in wholehearted agreement --- I've seen this
done successfully, but have never tried it myself.
> Since you're looking for a powerful macro language, it may be just what
> you want. It won't do "incremental assembly", but it's open source. If
> you can figure out what to do with forward references, perhaps it could
> be modified...
Requiring short jumps should be adequate --- that is pretty simple ---
and it is a draconian way to force programmers to factor their
functions down to reasonable size.
If that doesn't work, requiring near jumps is equally simple, although
it results in a performance hit.
>
http://tech.groups.yahoo.com/group/aoaprogramming/
>
> If that's the mailing list you tried to join, and got no response...
> maybe try again. Maybe try a different "reason" for wanting to join. The
> didn't do that when I joined, or I would have had to say, "I'm a spy
> from Nasm!" :) I think it's just an anti-spam measure - shouldn't matter
> what you say, as long as you say something. It *may* be that the "owner"
> of the group (not Randy, AFAIK) is 404, but the group is still "active"
> (not very) - Randy posted just the other day! I don't recall seeing many
> posts from "new" members, mostly the "regulars", so there might be a
> problem joining(?). We could inquire, if you continue to have trouble
> with it - get back to us.
What does 404 mean?
If it means that he is on vacation, then that is the most likely
explanation. I'll give them another week and if there is no response
I'll get back to youse.