mirror of
https://github.com/gomson/TimothyLottes.github.io.git
synced 2026-08-04 14:48:49 +00:00
Add files via upload
This commit is contained in:
TimothyLottes
GitHub
@@ -0,0 +1,82 @@
|
||||
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
|
||||
<h1>20150422 - Source-Less Programming : 2</h1>
|
||||
<br>
|
||||
|
||||
<i>Continuing with what will either be an insanely great or amazingly stupid project...</i><br>
|
||||
<br>
|
||||
Making slow progress with bits of free-time after work, far enough thinking through the full editor design to continue building. Decided to ditch 64-bit long mode for 32-bit protected mode. Not planning on using the CPU for much other than driving more parallel friendly hardware... so this is mostly a question of limiting complexity.
|
||||
Don't need 16 registers and the REX prefix is too ugly for me to waste time on any more.
|
||||
The 32-bit mode uses much more friendly mov reg,[imm32] absolute addressing,
|
||||
also with ability to use [EBP+imm32] without an SIB byte (another thing I mostly avoid).
|
||||
Unfortunately still need relative addresses for branching.
|
||||
32-bit protected mode thankfully doesn't require page tables unlike 64-bit long mode.
|
||||
Can still pad out instructions to 32-bits via reduntant segment selectors.<br>
|
||||
<br>
|
||||
<b>Source-Less Analog to Compile-Time Math?</b>
|
||||
<br>
|
||||
Compile-time math is mostly for the purpose of self-documenting code:
|
||||
"const uint32_t willForgetHowICameUpWithThisNumber = startHere + 16 * sizeof(lemons);".
|
||||
The source-less analog is to write out the instructions to compute the value,
|
||||
execute that code at edit time, then have anotations
|
||||
for 32-bit data words which automatically pull from the result when building 32-bit words for opcode immediates for the new binary image.<br>
|
||||
<br>
|
||||
<b>Reduced Register Usage Via Self Modifying Code</b>
|
||||
<br>
|
||||
Sure, kills the trace cache in two ways, what do I care.
|
||||
Sometimes the easist way to do something complex is to
|
||||
just modify the opcode immediates before calling into the function...
|
||||
<br>
|
||||
<br>
|
||||
<b>What Will Annotations Look Like?</b>
|
||||
<br>
|
||||
The plan so far is for the editor to display a grid of 8x8 32-bit words.
|
||||
Each word is colored according to a tag annotation
|
||||
{data, absolute address, relative address, pull value}.
|
||||
Each word has two extra associated annotations {LABEL, NOTE}.
|
||||
Both are 5 6-bit character strings.
|
||||
Words in grid get drawn showing {LABEL, HEX VALUE, NOTE} as follows,<br>
|
||||
<br>
|
||||
<tt>
|
||||
LABEL<br>
|
||||
00000000<br>
|
||||
NOTE</tt><br>
|
||||
<br>
|
||||
The LABEL provides a name for an address in memory (data or branch address).
|
||||
Words tagged with absolute or relative addresses or pull value show in the NOTE field
|
||||
the LABEL of the memory address they reference.
|
||||
Words tagged with data use NOTE to describe the opcode, or the immediate value.
|
||||
Editor when inserting a NOTE can grab the data value from other words
|
||||
with the same NOTE (so only need to manually assemble an opcode once).
|
||||
Edit-time insert new words, delete words, and move blocks of words,
|
||||
all just relink the entire edit copy of the binary image.
|
||||
ESC key updates a version number in the edit copy,
|
||||
which the excuting copy sees triggering it to replace itself
|
||||
with the edit copy.
|
||||
<br>
|
||||
<br>
|
||||
<b>Boot Strapping</b>
|
||||
<br>
|
||||
I'm bootstrapping the editor in NASM in a way that I'll be able
|
||||
to see and edit later at run-time.
|
||||
This is a time consuming process to get started
|
||||
because instead of using NASM to assemble code,
|
||||
I need to manually write the machine code to get the 32-bit padded opcodes.
|
||||
Once enough of the editor is ready,
|
||||
I need a very tiny IDE/PATA driver to be able to store to the disk image.
|
||||
Then I can finish the rest of the editor in the editor.
|
||||
Then I'll also be self hosted outside the emulator
|
||||
and running directly on an old PC with a non-USB keyboard,
|
||||
but with a proper PCIe slot...<br>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</div></body></html>
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
|
||||
<h1>20150423 - Source-Less Programming : 3</h1>
|
||||
<br>
|
||||
|
||||
<b>Annotation Encoding</b>
|
||||
<br>
|
||||
Refined from last post, two 32-bit annotation words per binary image word,<br>
|
||||
<br>
|
||||
<tt>FEDCBA9876543210FEDCBA9876543210<br>
|
||||
================================<br>
|
||||
00EEEEEEDDDDDDCCCCCCBBBBBBAAAAAA - LABEL : 5 6-bit chr string ABCDE</tt><br>
|
||||
<br>
|
||||
<tt>FEDCBA9876543210FEDCBA9876543210<br>
|
||||
================================<br>
|
||||
..............................00 - DAT : hex data<br>
|
||||
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA01 - GET : get word from address A*4<br>
|
||||
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA02 - ABS : absolute address to A*4<br>
|
||||
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA03 - REL : relative address to A*4</tt><br>
|
||||
<br>
|
||||
Going to switch to just 2 lines per word displayed in the editor,
|
||||
Only DAT annotations show hex value, other types show LABEL of referenced address
|
||||
in the place of the hex value. So no need for an extra note.
|
||||
In practice will be using some amount of binary image memory to build up
|
||||
a dictionary of DAT words representing all the common somewhat forth like opcodes,
|
||||
then GET words in the editor to build up source.<br>
|
||||
<br>
|
||||
Need to redo the bootloader from floppy to harddrive usage,
|
||||
and switch even the bootloader's 16-bit x86 code to 32-bit aligned
|
||||
LABEL'ed stuff so the final editor can edit the bootloader.
|
||||
Prior was avoiding manually assembling the 16-bit x86 code in the boot loader,
|
||||
but might as well ditch NASM and use something else to bootstrap everything.
|
||||
|
||||
|
||||
|
||||
</div></body></html>
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
|
||||
<h1>20150424 - Source-Less Programming : 4</h1>
|
||||
<br>
|
||||
|
||||
<i>Still attempting to fully vet the design
|
||||
before the bootstrap reboot...</i><br>
|
||||
<br>
|
||||
DAT words in the edit image need to maintain
|
||||
their source address in the live image
|
||||
This way on reload the live data can be copied over,
|
||||
and persistent data gets saved to disk.
|
||||
DAT annotations no longer have 30 bits of free space,
|
||||
instead they have a live address.
|
||||
When live address is zero. then DAT words
|
||||
won't maintain live data.
|
||||
This way read-only data can be self-repairing
|
||||
(as long as the annotations don't get modified).
|
||||
Going to use a different color for read-only DAT words.
|
||||
New persistent data DAT words
|
||||
will reference their edit-image hex value
|
||||
before reload (then get updated to the live address).
|
||||
<br>
|
||||
<br>
|
||||
REL words always get changed on reload (self repairing).
|
||||
No need to keep the live address.
|
||||
REL is only used for relative branching x86 opcodes.
|
||||
Don't expect to have any run-time (non-edit-time)
|
||||
self-modifying of relative branch addresses.
|
||||
Given that branching to a relative branch opcode immedate
|
||||
is not useful, the LABEL of a REL word is only useful
|
||||
as a comment.
|
||||
<br>
|
||||
<br>
|
||||
GET words also get changed on reload (self repairing).
|
||||
GET is only designed for opcodes and labeled constants.
|
||||
GET words will often be LABELed as a named branch/call target.
|
||||
Been thinking about removing GET, and instead making a new
|
||||
self-annotating word (display searches for a LABELed DAT
|
||||
word with the same image value, then displays the
|
||||
LABEL instead of HEX).
|
||||
This opens up the implicit possibility of mis-annotations.
|
||||
Would be rare for opcodes given they are large 32-bit values.
|
||||
But for annotating things like data structure immediate offsets,
|
||||
this will be a problem
|
||||
(4 is the second word offset in any structure).
|
||||
<br>
|
||||
<br>
|
||||
ABS words always get changed on reload (self repairing).
|
||||
ABS words are targets for self-modifying code/data,
|
||||
so they also need LABELs.
|
||||
Reset on reload presents a problem in that
|
||||
ABS cannot be used to setup persistent data
|
||||
unless that persistent data is constant
|
||||
or only built/changed in the editor.
|
||||
But this limitation makes sense in the context
|
||||
that ABS addresses in live data structures
|
||||
can get invalidated by moving stuff around in memory.
|
||||
The purpose of ABS is edit-time relinking.
|
||||
<br>
|
||||
|
||||
|
||||
</div></body></html>
|
||||
|
||||
|
||||
|
||||
@@ -93,6 +93,9 @@ Below this is active random migration (400 prior posts still to filter through)
|
||||
<a href="20150522.html">20150522 - The Other Project Cleaned Up</a><br>
|
||||
<a href="20150430.html">20150430 - The Other Project Getting Wired</a><br>
|
||||
<a href="20150426.html">20150426 - Source-Less Programming : 5</a><br>
|
||||
<a href="20150424.html">20150424 - Source-Less Programming : 4</a><br>
|
||||
<a href="20150423.html">20150423 - Source-Less Programming : 3</a><br>
|
||||
<a href="20150422.html">20150422 - Source-Less Programming : 2</a><br>
|
||||
<a href="20150416.html">20150416 - Pixel Art and Slot Mask Pitch</a><br>
|
||||
<a href="20150415.html">20150415 - Indie vs Real Slug Fest</a><br>
|
||||
<a href="20150328.html">20150328 - Stills From My Talk</a><br>
|
||||
|
||||
Reference in New Issue
Block a user