I honestly forgot what I was going to say one second

oh something about adding code labels

Probably the biggest thing that we need in a new assembler is labels

since GCC emits them and they're useful for creating symbol tables

I'm kinda concerned about how much we add though since it'll deviate away from the interpreter

I was kind of thinking that the QFTASM interpreter could kind of interpret just the emitted bytecode but in assembly format (if that makes any sense), whereas our assembler would support some of the nice syntax sugar most offer

I suppose that would also be the domain of @El'endiaStarman

This is basically the flow I'm envisioning at the end though:

Frontend (code to assembly; GCC, Cogol, QFTASM lang) -> Assembler (assembly to ELF files, but maintaining the QFTASM text in a separate section as well as the byte code) -> Linker (ELF files to ROM) or QFTASM interpreter (takes in that preprocessed text format and data section)

Yeah, the assembler is kind of a preprocessor

But I think it would also output the byte stream that would get put in the ROM too, or at least the code for a given symbol

the linker would put it together afterwareds

ELF files are delightfully flexible and we can put more or less anything in them

So we could preserve some kind of QFTASM plaintext section that would go into the interpreter

The interpreter will need to have something new for the preinitialized RAM from the data section though

direct write only does one at a time

@Mego The question is is the interpreter simulating the computer or the assembler and the computer

What scope/role should it have

Personally I don't want to have to sync changes from the assembler (presumably Python) to the interpreter (ES5 JS)

Then it should probably take basically what the computer takes, just in plaintext for copy-pasting

That is, the current QFTASM with no assembly directives or labels

also found a library for actually writing elf files: pypi.python.org/pypi/elffile/0.005

old but libelf hasn't been updated since 2009 either, there's just not a lot of things to add

although I just tried to install it and it threw an ImportError?

ok

thanks

ModuleNotFoundError: No module named 'coding' hmmm

I have an editing question for you all. There seem to be one or two typoes in each post. Would you mind if I went in and made some corrections?

@Sherlock9 Typos? In my post? Nevah! (I jest; I don't mind.)

@El'endiaStarman I've just read through your post again. I don't see any typoes but I have one or two grammatical gripes. "Simply a strip of blue bordered by strips of green." is a sentence fragment, for one

For another, the ANT gate explanation maybe helped by pointing out which incoming signal is A and which is B

Alright decided not to edit the ANT signal explanation. Nowhere to put it where it wouldn't be awkward

@Mego Already on it o7

I'm editing Part 3 a little heavier than I expected to. When I've finished could you look over my edits to make sure I didn't overstep anywhere?

Finished editing Part 3, starting on Part 4

Question about this sentence in Part 4: "Furthermore, ANT is versatile and has its main advantage masking: in the case of the Tetris program we use it to erase tetronimoes." What does "its main advantage masking" mean here?

Okay another question, have any of you noticed that you have 11 opcodes assigned out of 16 possibilities?

Right, but I was asking because Phi said 10 in Part 4

Never mind, already fixed

Ah fair enough

Also, I have been meaning to ask how on earth you do the graphical output

@Mego Oh, I see. So how shall I edit this sentence to reflect that: "The opcode is 4 bits to support 16 unique opcodes, of which 10 are assigned:"

Or should I just say "11 are assigned" and move on the next section?

@Mego Okay I think I understand. Cool :D

Alright so I'll say "The opcode is 4 bits to support 16 unique opcodes, of which 10 are assigned (SRA is too complicated to build into the hardware, so in the ROM, we translate SRA into an equivalent series of commands built out of the other 10):"

Or "so when we build the ROM, SRA is translated into"

Okay, what does the branch delay slot section mean? I'm having trouble grasping the implications

@Mego Oh I see

I might want to edit that in later, but I'll have to save my work and continue later

I did edit in, perhaps a bit inelegantly, but step 2 now ends with the paragraph: "In short, because the previous instruction's output..."

@Mego I thought @KZhang did implement SRA in hardware?

...shoulda kept reading...

@Mego btw turns out the problem was that it was including elffile to get its docstring before the install requirements were resolved

for whatever reason

I just ended up not using the setup

the only dependency really is coding

everything else is for unit tests