compile-time variables

[Hugh Aguilar]

I posted the following on alt.lang.asm but was referred here.
http://groups.google.com/group/alt.lang.asm/browse_thread/thread/bf11375d1db692e0#
I'm writing a Forth compiler.

BTW, I've never been able to get registered on Randy Hyde's forum:
http://tech.groups.yahoo.com/group/aoaprogramming/
Does anybody know what is going on over there? Are they still active?

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

I'm confused about HLA compile-time variables. I want to use them as
constants, but HLA complains about this.

Here is my offending macro:

#macro forth0( mask , string forth_name ) : entrance, start, finish, beyond, node;
    entrance:
        commence0;
    start:
#terminator end_forth0;
    finish:
        conclude0;
    beyond:
    static
    node : header := header:[ head, 0, &entrance, forth_name, 0, mask, &start, &finish, &beyond, 0, 0 ];
    ?head := &node;
    endstatic;
#endmacro;

Don't worry about most of this; it is okay. The COMMENCE0 and
CONCLUDE0 macros generate code okay. the header record is getting
filled okay, and it is assembled at the NODE label in the STATIC
section. The problem is this line:

    ?head := &node;

That gives me this error message:

Error in file "ToyForth.hla" at line 1156 [errid:536/oututils.c]:
Object "_0954_node_t_" was used as an address expression in the
statement at line 153, it must be defined within the scope of the
object.
Near: << ; >>

Line 153 is the line mentioned above inside of the macro. Line 1156 is
the last line of the program:

end ToyForth;

We seem to have gotten past all of the parsing, and we are into the
HLA pass that resolves all of the hanging references.

I also have a few dozen error messages that object to my using a
compile-time variable as a CASE argument in a SWITCH statement. All of
these variables were originally set to equal HEAD immediately after
the FORTH0 and END_FORTH0 macros were called. Those get set once and
are never changed, so they are effectively constants. By comparison,
HEAD gets set every time that the END-FORTH0 macro is called. There is
a line early on in the file that initializes HEAD to 0 (it is the head
of the linked list that is being built by all of those FORTH0 and
END_FORTH0 macros).

If none of this makes any sense, let me know --- I will try to
reproduce the error with a short test file that would be more easily
understood. Thanks in advance for your help.

[Hugh Aguilar]

Here is my offending macro:

BTW, this worked in the past AFAIK. Everything seemed to be fine, so I went ahead and wrote code using the macro dozens of times. Then it no longer worked and I got the error message described above. AFAIK, however, I'm using it consistently throughout, so I don't know where I went wrong.

This makes me think that maybe HLA has a problem with the macro being used too many times. Maybe there is a limit on how many STATIC sections there can be.

It looks like good HLA code --- I'm baffled about why it doesn't work. This is my first HLA program though, so it is more likely something that I'm doing wrong, rather than a problem with HLA.

I'm very frustrated with not being able to get on the HLA mailing list. If I do end up abandoning HLA (as pretty much everybody says that I should), it will be because of the lack of support from the HLA community --- HLA itself may very well be a good assembler, but I'll never learn enough about it to know.

[Hugh Aguilar]

I'm confused about HLA compile-time variables. I want to use them as
constants, but HLA complains about this.
...
I also have a few dozen error messages that object to my using a
compile-time variable as a CASE argument in a SWITCH statement.

What I mean by this is that when I use a VAL compile-time variable in a CASE, I get an error message that says:
Unexpected constant type, expected ordinal constant.

I don't declare my variables in a VAL section; I just assign them with a ?xxx := yyy; statement. How could they not be ordinal? They are assigned to an address, which is just a 32-bit number. Do they have to be predeclared in a VAL section? The assembler doesn't seem to be complaining about their lack of predeclaration.

Is there anybody out there who can answer questions about HLA? Is there some way for me to get onto the HLA mailing list so I could ask these questions there? I would hate to have to abandon HLA because of something like this, which is most likely just a simple mistake on my part, but I'm pretty much stopped by this failure to assemble. I thought that I understood this stuff, and I was assembling without any problem, but then it just stopped working.

[Sevag.K]

the mailing list moderator seems to be AWOL.  i'm pretty good with hla myself, but not too versed in the CTL and i haven't been doing much work with hla lately due to other unavoidable concerns.  it may not be possible to use a compile time variable in a CASE statement since it is a macro and the macro itself is processed at compile time.  not sure on this one.

[Hugh Aguilar]

the mailing list moderator seems to be AWOL.  i'm pretty good with hla myself, but not too versed in the CTL and i haven't been doing much work with hla lately due to other unavoidable concerns.  it may not be possible to use a compile time variable in a CASE statement since it is a macro and the macro itself is processed at compile time.  not sure on this one.

What I'm trying to do is not particularly complicated. It is just the creation of a linked list at compile-time.

I think that it was a big mistake to try to use a built-in macro language. The assembler and the macro-language that produces assembly source-code should be two separate programs, rather than one monolithic program.

I would have been much better off to write my own macro language using a common HLL (such as Scheme or Python or Forth) as a front-end for some assembler. I think that I will do that. If Randy Hyde et. al. were supporting HLA I would be more enthusiastic about HLA, but they aren't, so forget about HLA. It is unrealistic for me to learn the intricacies of their macro language without any help --- I am better off to spend my time writing my own macro language, rather than struggling to learn their macro language on the assumption that they know more about how to write a macro language than I do.

Randy Hyde seems to be pretty much a Pascal programmer, which is not a language that I'm interested in. Pascal was the teaching language of the 1980s, and Randy Hyde strove to get HLA adopted as Pascal's successor in the schools --- but I'm not a schoolboy, so why should I care? --- besides that, the schools have all agreed on Java as the successor to Pascal.

This is all a huge disappointment to me. I really thought that HLA was going to be a worthwhile language for me, and I learned quite a lot about HLA (it really does have some cool features). But if Randy Hyde himself has abandoned HLA then so shall I.

[brethren]

But if Randy Hyde himself has abandoned HLA then so shall I

i'm genuinely curious, what makes you think he's abandoned hla?

you've got his latest book on hla released about 18 months ago (chapter 9-Macros and the hla compile-time language would probably help)
http://www.amazon.com/Art-Assembly-Language-Randall-Hyde/dp/1593272073/ref=pd_sim_b_2

and sourceforge shows he's still updating his projects
http://sourceforge.net/users/rhydehla

[Sevag.K]

he hasn't abandoned it.  it's just that hla is a small community and most of us get real busy this time of year.  hyde has a business to attend to as well.
the problem seems to be compounded by the fact that the moderator for the aoaprogramming group seems to have abandoned the group without passing on the account to someone active. 

[Hugh Aguilar]

But if Randy Hyde himself has abandoned HLA then so shall I

i'm genuinely curious, what makes you think he's abandoned hla?

I think that he has abandoned HLA because I can't get on the HLA mailing list.

When applying for the mailing list, it is necessary to write a brief explanation of why you want to get on the mailing list. I said that expected HLA to be similar to Forth in that both rely heavily on compile-time programming. It is possible that Randy Hyde rejected me because he was offended by the comparison to Forth --- that he hasn't abandoned HLA, but that he considers Forthers to be inherently incompetent and he won't associate with us. Either way, it is the same to me.

My HLA program is now over 1100 lines long. I was doing okay with HLA and thought that I understood it pretty well, although I was sticking with a fairly simple usage (just writing plain assembly, and not using any of the Pascalish stuff). Now I've got error messages that I don't understand, so I have to just abandon HLA and switch to another assembler. These may be the result of a simple misunderstanding on my part (likely, as this is my first HLA program), or they may be the result of a problem in HLA.

Sevag.K suggested that compile-time variables may not be usable as CASE arguments because they and SWITCH/CASE are all evaluated in the same pass. If so, then that is a problem in HLA. I know that FASM has multiple passes, with compile-time variables being evaluated in an early pass and being available for use in latter passes. I'm switching over to FASM and hopefully that will work. This is not complicated stuff --- it should be trivial --- I've used plenty of assemblers (non-x86) in the past and done similar stuff without problem, so it shouldn't be a big deal.

As for that other error message, that one is a complete mystery. The macro in question worked fine in the past. Then I wrote a lot of code using that macro, and suddenly I get this weird error message --- but I never changed the macro itself from when it was working, and my use of the macro is consistent and straight-forward throughout.

Anyway, I've lost patience with HLA. I've been trying to get on the HLA mailing list since October; it is obvious now that I will never get on the HLA mailing list. The program that I'm writing is not very complicated --- I can't dink around with HLA forever --- I'll just use another assembler. I am annoyed that Randy Hyde trumpets HLA's compile-time language as being far superior to other assemblers' macro languages, and yet I am running into difficulty writing compile-time code that I know would be trivial in the more traditional assemblers that I have used in the past.

I doubt that most of the cool features of HLA, such as the procedures, are actually written in the HLA compile-time language --- they are most likely integral to HLA (written in flex/bison and all that) --- but I haven't delved into HLA's source-code, so I don't really know if this is true or not. As I said, what I'm doing is simple stuff --- people were implementing Forth in assembly way back in the 1970s (the FIG green-books) --- so why is HLA having difficulty with this stuff in the year 2011?

I might return to HLA in the future; for example, when I write the IDE for the compiler I could use HLA rather than C. For now though, I'm sick of dinking around with HLA, and I don't need all of that Pascalish stuff anyway, so I'm just going to switch over to a more traditional assembler and get on with my project.

[jj2007]

It is possible that Randy Hyde rejected me because he was offended by the comparison to Forth --- that he hasn't abandoned HLA, but that he considers Forthers to be inherently incompetent and he won't associate with us.

That is extremely unlikely. Consider more trivial explanations, such as your mail got lost, or Randy's on sabbatical etc - you seem to take this "refusal" very personal. HLA has indeed a small community, that is most likely the cause.

Consider joining the Masm32 community - we have some damn good macro coders here. A Forum search for MACRO yields about 3,000 threads :dazzled:
And if you have any doubts about the MASM (and JWasm) macro engine, check the MasmBasic help file. Forth should be simpler to implement.

[dedndave]

not to mention - Randy Hyde probably gets a zillion e-mails a week   :P

[Hugh Aguilar]

It is possible that Randy Hyde rejected me because he was offended by the comparison to Forth --- that he hasn't abandoned HLA, but that he considers Forthers to be inherently incompetent and he won't associate with us.

That is extremely unlikely. Consider more trivial explanations, such as your mail got lost, or Randy's on sabbatical etc - you seem to take this "refusal" very personal. HLA has indeed a small community, that is most likely the cause.

I tend to be somewhat sensitive to this kind of thing. I'm painfully aware that Forth has a very bad reputation (primarily because Forth Inc. sells garbage, and casual observers believe that Forth Inc. represents Forth because of the name). A lot of people (mostly C programmers) routinely state that Forthers are incompetent and that Forth was "proven" to be inferior to C in 1994 when ANS-Forth was made public and was seen to be a complete failure in language design. ANS-Forth really was awful --- I'm not to blame for this fiasco however --- my novice package provides work-arounds for many of ANS-Forth's problems, so I'm making a positive contribution.

Forth has a "small community" too --- learning HLA is like jumping out of the frying pan and into the fire --- I'm never going to get a job if I continue to focus on esoteric languages that few people have heard of (and the few who have heard of them say they are no good).

Consider joining the Masm32 community - we have some damn good macro coders here. A Forum search for MACRO yields about 3,000 threads :dazzled:
And if you have any doubts about the MASM (and JWasm) macro engine, check the MasmBasic help file. Forth should be simpler to implement.

I've programmed in MASM and TASM in the past (MS-DOS days). Other than being confused by all the memory-model directives, I found it to be a reasonably good system. The macro language worked pretty well. LMI's UR/Forth was written in MASM. The place where I worked actually had the source-code to UR/Forth (they are likely the only people in the world that have it now that LMI is out of business). I never saw the full source-code because I hadn't signed the nondisclosure statement, but I did study the MASM source-code files that were provided with UR/Forth to the common users. I also disassembled a lot of UR/Forth. All in all, I was pretty familiar with how MASM was used to implement Forth.

Unfortunately, I can't get involved in a Windows-specific closed-source proprietary system in the year 2012. I want to support both Windows and Linux. I foresee that Linux will eventually obsolete Windows, which is getting worse rather than better (Vista was awful!). This means HLA, NASM or FASM. A point in favor of FASM is that there is an ARM version of FASM, so a lot of what I learn while programming x86 code will carry over when I start programming ARM code. There is no money to be made in x86 programming; pretty much all x86 software is given away for free (other than games, which I don't want to get involved in) --- if I'm going to make money at programming again, I would have to do ARM programming --- to paraphrase Willie Sutton: "Because that's where the money is."   :U

[jj2007]

I can't get involved in a Windows-specific closed-source proprietary system in the year 2012. I want to support both Windows and Linux.

JWasm has no license problems and is a perfect clone of Masm. Use a ForLinux or whatever switch and write a macro library, that's all.

[Sevag.K]

But if Randy Hyde himself has abandoned HLA then so shall I

i'm genuinely curious, what makes you think he's abandoned hla?

I think that he has abandoned HLA because I can't get on the HLA mailing list.

When applying for the mailing list, it is necessary to write a brief explanation of why you want to get on the mailing list. I said that expected HLA to be similar to Forth in that both rely heavily on compile-time programming. It is possible that Randy Hyde rejected me because he was offended by the comparison to Forth --- that he hasn't abandoned HLA, but that he considers Forthers to be inherently incompetent and he won't associate with us. Either way, it is the same to me.

for the record, randy doesn't run the aoaprogramming mailing list.  the one who does seems to have gone inactive.
hla does not rely on compile-time programming and your love of forth would not exclude you from the list, if there was an active moderator on the list.

My HLA program is now over 1100 lines long. I was doing okay with HLA and thought that I understood it pretty well, although I was sticking with a fairly simple usage (just writing plain assembly, and not using any of the Pascalish stuff). Now I've got error messages that I don't understand, so I have to just abandon HLA and switch to another assembler. These may be the result of a simple misunderstanding on my part (likely, as this is my first HLA program), or they may be the result of a problem in HLA.

Sevag.K suggested that compile-time variables may not be usable as CASE arguments because they and SWITCH/CASE are all evaluated in the same pass. If so, then that is a problem in HLA. I know that FASM has multiple passes, with compile-time variables being evaluated in an early pass and being available for use in latter passes. I'm switching over to FASM and hopefully that will work. This is not complicated stuff --- it should be trivial --- I've used plenty of assemblers (non-x86) in the past and done similar stuff without problem, so it shouldn't be a big deal.

switch/case in hla is a complicated macro that uses jump tables and heavy processing.  i find it hard to believe that the usage of an optional macro is a deal breaker for you.  have you tried creating a custom switch/case macro or perhaps use conditional instructions instead?

As for that other error message, that one is a complete mystery. The macro in question worked fine in the past. Then I wrote a lot of code using that macro, and suddenly I get this weird error message --- but I never changed the macro itself from when it was working, and my use of the macro is consistent and straight-forward throughout.

did the error message begin after you updated hla version?  if so, a bug could have crept in.  you could try switching back to an older version and report the bug.

I doubt that most of the cool features of HLA, such as the procedures, are actually written in the HLA compile-time language --- they are most likely integral to HLA (written in flex/bison and all that) --- but I haven't delved into HLA's source-code, so I don't really know if this is true or not. As I said, what I'm doing is simple stuff --- people were implementing Forth in assembly way back in the 1970s (the FIG green-books) --- so why is HLA having difficulty with this stuff in the year 2011?

I might return to HLA in the future; for example, when I write the IDE for the compiler I could use HLA rather than C. For now though, I'm sick of dinking around with HLA, and I don't need all of that Pascalish stuff anyway, so I'm just going to switch over to a more traditional assembler and get on with my project.

good luck to you.

[Hugh Aguilar]

switch/case in hla is a complicated macro that uses jump tables and heavy processing.  i find it hard to believe that the usage of an optional macro is a deal breaker for you.  have you tried creating a custom switch/case macro or perhaps use conditional instructions instead?

That did help. I had been assuming that the problem was in the compile-time variables, which is a pretty serious problem. Actually, the problem is just that SWITCH doesn't work. Here is a test program:

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

begin tester;

alpha:
    ?beta := &alpha;

    if( eax = &alpha )      then    mov( 1, ebx );
    elseif( eax = beta )    then    mov( 2, ebx );
    endif;
   
    // switch( eax )
    // case( &alpha )  mov( 1, ebx );
    // case( beta )    mov( 2, ebx );
    // endswitch;

end tester;

The commented out code involving the SWITCH will not assemble; it will give the error described previously. The code involving the IF ELSEIF ENDIF does assemble though, which indicates that compile-time variables are working. This means that I can rewrite all of my SWITCH statements to use IF ELSEIF ENDIF instead. A bug in SWITCH is not a deal-breaker as I can work around it.

I still have that other weird error message to worry about, but this is a step in the right direction.

I'll continue working with (dinking around with) HLA for a while. I'm not enthusiastic about this at all. It is not my goal to become an expert on HLA in the sense that I know about bugs in HLA that nobody else knows about. That would only be meaningful if there were HLA-programming jobs available and I could edge out the other candidates on the basis of my secret knowledge of HLA bugs. I would much prefer to be a part of the HLA community --- it is just a hobby after all --- sharing information helps everybody.

did the error message begin after you updated hla version?  if so, a bug could have crept in.  you could try switching back to an older version and report the bug.

Nope.

[Hugh Aguilar]

ue working with (dinking around with) HLA for a while. I'm not enthusiastic about this at all. It is not my goal to become an expert on HLA in the sense that I know about bugs in HLA that nobody else knows about. That would only be meaningful if there were HLA-programming jobs available and I could edge out the other candidates on the basis of my secret knowledge of HLA bugs. I would much prefer to be a part of the HLA community --- it is just a hobby after all --- sharing information helps everybody.

I got on the HLA mailing list, and I also got my program to assemble again --- so my enthusiasm for HLA has improved considerably.