db saves one byte over dw, guaranteed. align 8, on average, will cost 4 bytes for randomly aligned code. So, overall you lose 3 bytes per function. Normally this won't matter a toss but since the idea was to save bytes then it kinda defeats the purpose, yeah.

I've never coded in a random manner - how does that work for you?

My code is extremely random. Haven't you noticed?

Nah, I haven't seen it, but if you say random then I'll take your word for.

As odd as it sounds, I'm putting alot of thought into this particular part of my code - because the lexer will do it for every last byte of the source file during runtime.

I like this, it answers my original question. : )


I'm now thinking to use lodsb + xlatb to pull the offset. I know there are register stalls in there, but I'm more worried about cache misses and fitting it tight. Once I have it working at all, the next stage will be to write the reverse-lexer to scan it from both ends on multiprocessors for double the speed.

strings, arrays, expressions, multi-line comments, whitespace and parens can share code between the forward and reverse lexers.

Am I crazy?

Suggestion: Get it working first, then make it faster.

Yeah, I don't take advice so much. I'm too high on my royal horse. But I will read the article, so thanks.

In my not-so-humble opinion there are major code structure differences between the different ways of doing it so that the written code of one doesn't resemble the other mooting the point of writing anything but the correct solution.



I've already implemented working lexer/parsers, so while I'm still pretty rookie with optimizing assembler this is about reinventing the wheel round. There's no point in doing it if the wheel's a hexagon or square like the last one.

So far I have a 72-byte algorithm and a 256-byte jump table that consumes any amount of lines and whitespace
correctly - which to me means I just need to add and test handler cases for each of the remaining tokens before I want to profile and bench the lexical analysis to see what's up.

To get the second processor running the source backwards, I simply do this:

- std for only that processor.
- give it a different table where most of the offsets are the same, but some are different. Make sure each table is only loaded on it's processor's cache.
- provide handler cases for tokens that aren't penundromes (sp?) like line comments, flow control structures, and a reverser for identifiers before using the normal means for that.[/quote]