A few weeks ago, I added the FlatAssembler-like `display` command to the preprocessor of my PicoBlaze Simulator in JavaScript, for printing strings and calculated constants to the terminal during assembly. However, there is a weird bug in it. The preprocessor ignores the `display a` (for writing the new-line character, whose ASCII code is 0xA) command if the UART simulation is disabled during assembly.
For example, if you assemble the "Preprocessor Test" example (the 8th example from the left in the flexbox with the example programs) while UART simulation is disabled, the preprocessor outputs this:
![[Image: 260815935-4be68410-9cc8-4e96-87cb-17b7b5d6a20b.png]](https://user-images.githubusercontent.com/46264381/260815935-4be68410-9cc8-4e96-87cb-17b7b5d6a20b.png)
But if you assemble it while UART simulation is enabled, it outputs this:
![[Image: 260816137-ad6da82c-54b7-4955-b2bd-ea54e9cd4dcc.png]](https://user-images.githubusercontent.com/46264381/260816137-ad6da82c-54b7-4955-b2bd-ea54e9cd4dcc.png)
At first, I thought that perhaps setting the innerHTML of a hidden (display:none) <pre> element in JavaScript deletes the new-line characters for some reason. But I've tested that hypothesis (by making a short HTML5 program that sets the innerHTML of a hidden <pre> element and then shows it) and it has proven wrong. I have no idea how that's possible. How can the preprocessor even know whether the UART simulation is enabled? How would I go about diagnozing the problem more precisely?
I have opened a GitHub issue about this:
https://github.com/FlatAssembler/PicoBla...S/issues/8
The code with which the `display` command is implemented is here:
For example, if you assemble the "Preprocessor Test" example (the 8th example from the left in the flexbox with the example programs) while UART simulation is disabled, the preprocessor outputs this:
But if you assemble it while UART simulation is enabled, it outputs this:
At first, I thought that perhaps setting the innerHTML of a hidden (display:none) <pre> element in JavaScript deletes the new-line characters for some reason. But I've tested that hypothesis (by making a short HTML5 program that sets the innerHTML of a hidden <pre> element and then shows it) and it has proven wrong. I have no idea how that's possible. How can the preprocessor even know whether the UART simulation is enabled? How would I go about diagnozing the problem more precisely?
I have opened a GitHub issue about this:
https://github.com/FlatAssembler/PicoBla...S/issues/8
The code with which the `display` command is implemented is here:
Code:
if (/^display$/i.test(node.text) &&
(
typeof PicoBlaze !==
"object" // Because UART_OUTPUT is not declared in PicoBlaze
// Simulator for Android, which we detect by `PicoBlaze`
// being declared.
)) {
if (node.children[0].text[0] == '"')
document.getElementById("UART_OUTPUT").innerText +=
node.children[0].text.substr(1, node.children[0].text.length - 2);
else {
const ASCIIValue =
node.children[0].interpretAsArithmeticExpression(context.constants);
if (ASCIIValue != '\n'.charCodeAt(0))
document.getElementById("UART_OUTPUT")
.appendChild(
document.createTextNode(String.fromCharCode(ASCIIValue)));
else
document.getElementById("UART_OUTPUT")
.appendChild(document.createElement(
"br")); // This doesn't appear to work in Firefox if UART is
// disabled while assembling, and I have opened a
// GitHub issue about that:
// https://github.com/FlatAssembler/PicoBlaze_Simulator_in_JS/issues/8
}
} else if (/^display$/i.test(node.text)) {
if (node.children[0].text[0] == '"') {
for (let i = 0; i < node.children[0].text.length; i++)
if (node.children[0].text[i] != '"')
PicoBlaze.displayCharacterOnTerminal(
node.children[0].text.charCodeAt(
i)); // Right now, `displayCharacterOnTerminal` is a
// no-operation in PicoBlaze_Simulator_for_Android.
} else {
PicoBlaze.displayCharacterOnTerminal(
node.children[0].interpretAsArithmeticExpression(
context.constants));
}
}
![[Image: extraordinarywoo-sig.jpg]](https://i.postimg.cc/zf86M5L7/extraordinarywoo-sig.jpg)
![[Image: MmQV79M.png]](https://i.imgur.com/MmQV79M.png)
