Here is the thread to deal with this problem.

Here is my code so far:

Attached Files

	pnfasm.lpp.txt (31.5 KB, 8 views)
	pnfasm.ypp.txt (49.4 KB, 8 views)

This extra string it requires in #define, is not just ugly and unnessassary, it produces code that won't work without manually removing the string.

Your previous thread was essentially a continuation of a conversation from several months ago in which I had offered specific advice. As such, I more or less continued with it based on that prior context.

If you are going to begin another related thread, let's start with a clean slate which includes the full context of this specific issue to make the information complete and more useful, and to encourage participation of others.

I am not sure what your question here is. You say that this won't work without manually removing some string, but it is really unclear what that means. What won't work, and how does it fail? What string? What is the overall context and point of the question?

Please see this page in the Site FAQ for help in posting your questions. In particular, the link at bottom of that page, How to Ask Questions the Smart Way.

Please provide a clear and repeatable example of the problem you are having, including the input, the result with any error messages, and a description of the expected behavior, so we can understand better what the issue is. If knowledge of your PNF language is necessary to understand it, then you must provide that.

Finally, looking quickly at the posted code I see that all my comments and suggestions from previous threads concerning better use of Flex, Bison and grammar would still apply, so there is no point in repeating those, yet again. I refer you to those previous threads for my own best advice as to where to start.

Well, good point. I'll start by seeing if I can improve the code, and then repost it. No point in putting extra information here until I finish that, but it was kind of a good follow up to post this even if it somehow solves it, but I doubt it will.

There. The main thing I learned from that previous discussion, of value to my "immediate" code, is that yytext shouldn't be used in the parser. I fixed that now. I changed references to yytext, mostly to $3. Here is my code again after applying everything I learned that is helpful for here for now.

Attached Files

	pnfasm.lpp.txt (31.6 KB, 7 views)
	pnfasm.ypp.txt (50.5 KB, 10 views)

PNFASM stands for "Portable Numbers Format Assembler". It is just an assembler for PNF, which is the actual "binary" language. This makes what I see as an easier language to use than most, easier again. PNF is easy for it's TYPE of language, not actually something the average programmer would jump to using.

Because of the simple job of changing text, this "could" be done by the preprocessor I just created, but it's much better to do it with another actual program than with libraries full of code. Then we get more power later on, like for now.

The code that I am working on now, is variants from the regular syntax, and is used to pass instructions onto the assembler on how to actually assemble the file correctly.

Okay. Now for some concrete examples of tests I am trying to get to work.

hello.pasm
This is a simple Hello World program. The new directives are what to pay attention to. "#PBIN#", is a directive that tells the assembler to generate a file that will need further preprocessing before it's run by the interpreter. "'!", signals a comment to be passed onto the preprocessor.

That is a directive that will tell the assembler to assemble in a preprocessing directive, which should assemble to:

That preprocessing directive, in turn will tell the preprocessor to change all instances of "0", to "1". That will actually make the resulting file interpret with errors, but for the test, that's what I wanted, just to see if the code I'm working on works or not. It may technically even be a dangerous thing to ask for, but for my test, that's okay. I'm willing to take the risk, to see if it works or not.

With this code, that should be correct, it doesn't actually work right for some reason. It wants me to say:

...Which will assemble to:

It passes the string onto the code as a literal string. The string shouldn't even be required in the first place. I don't see anywhere where I asked it for that string, but I've tried doing a deep cleaning and recompiling, and I get the same result. It's possible that the compiler has a cache somewhere that got corrupted, and my code is actually correct. But it may not be too.

Hopefully that is enough information. I will try to post better initial posts in the future, but it can be tricky for me...

If that was the main thing that you learned from previous threads, then you have still missed my often stated point that your immediate code implementation is the actual root of the various problems - you are attempting to do everything in your action code and making little or no use of the lexer, parser and grammar. Your problem in this thread, on first look, appears to be yet another manifestation of not having a functional lexer, parser and grammar.

Fixing your "immediate" code does not fix that problem, and never will.

The misuse of yytext was an important but incidental point. And in that case it took a repeated explanation before you actually considered it and acted on it.

I and others here are very willing to help, but you must consider and try to understand the suggestions on offer to benefit from them.

Should I put it on hold until I study compilers in its fullest?

What error are you getting that tells you to add the extra string? Is it a bison "syntax error" or something thrown from your own action code?

I see that you are building with the Bison -t option to enable debugging traces, have you looked at the trace to see how the input is being handled?

You can have it generate the trace by setting an integer yydebug variable to non-zero value in the prologue code or in your main() function and recompiling. It should produce a long but reasonable set of messages for the single line input above.

Please paste the trace here and confirm that it uses the above flex and bison code. That will tell us what the grammar is doing.

OK. Its a parser error by bisons code. Ill get back to you more later. Have to go to work now.

Here is the trace.

Attached Files

trace.txt (4.7 KB, 5 views)