<mark4>
my code is literally peppered full of bullshit branch target alignment and thers no fucking way to get rid of it
<mark4>
my code is literally peppered full of bullshit branch target alignment and thers no fucking way to get rid of it
f-a has quit [Quit: leaving]
f-a has quit [Quit: leaving]
<tabemann>
simple - write your kernel in assembly, and have it compile directly to machine code - of course, that limits you to one platform (without doing rewriting)
<tabemann>
simple - write your kernel in assembly, and have it compile directly to machine code - of course, that limits you to one platform (without doing rewriting)
boru` has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru has quit [Disconnected by services]
boru` is now known as boru
boru` is now known as boru
jedb__ has joined #forth
jedb__ has joined #forth
tabemann has quit [Remote host closed the connection]
tabemann has quit [Remote host closed the connection]
tabemann has joined #forth
tabemann has joined #forth
jedb_ has quit [Ping timeout: 256 seconds]
jedb_ has quit [Ping timeout: 256 seconds]
<MrMobius>
mark4, have you actually run it with and without the alignment?
<MrMobius>
mark4, have you actually run it with and without the alignment?
<mark4>
i have now, and the code is just fine without it
<mark4>
i have now, and the code is just fine without it
<MrMobius>
there is a video from I think cppcon that I cant find where the guy goes through a bunch of examples of the compiler outputting longer and less efficient looking code than a human but when you run it the compiler outperforms hand written code
<MrMobius>
there is a video from I think cppcon that I cant find where the guy goes through a bunch of examples of the compiler outputting longer and less efficient looking code than a human but when you run it the compiler outperforms hand written code
<mark4>
the lack of code optmization is not the bottleneck
<mark4>
the lack of code optmization is not the bottleneck
<mark4>
yes its very difficult these days to be the compilers performance
<mark4>
yes its very difficult these days to be the compilers performance
<mark4>
however. this code will perform no worse at -O0 than at -O3
<mark4>
however. this code will perform no worse at -O0 than at -O3
<mark4>
so.. -Oz or -Os make sense
<mark4>
so.. -Oz or -Os make sense
<MrMobius>
right. also seems hard to even evaluate compiler output too since just looking at it is now not even enough. you cant really conclude anything until you run both versions
<MrMobius>
right. also seems hard to even evaluate compiler output too since just looking at it is now not even enough. you cant really conclude anything until you run both versions
<mark4>
i have
<mark4>
i have
<mark4>
i am now compiling with no padding to align anything
<mark4>
i am now compiling with no padding to align anything
<MrMobius>
right I just mean generally speaking
<MrMobius>
right I just mean generally speaking
<mark4>
ya. i see no difference
<mark4>
ya. i see no difference
<mark4>
i wish i had my old p3-650 to run it on :)
<mark4>
i wish i had my old p3-650 to run it on :)
<mark4>
that would tell me
<mark4>
that would tell me
sts-q has quit [Ping timeout: 256 seconds]
sts-q has quit [Ping timeout: 256 seconds]
sts-q has joined #forth
sts-q has joined #forth
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #forth
_whitelogger_ has joined #forth
gravicappa has joined #forth
gravicappa has joined #forth
<proteus-guy>
mark4, you compiling something in C?
<proteus-guy>
mark4, you compiling something in C?
f-a has joined #forth
f-a has joined #forth
cheers- has quit [Quit: cheers-]
cheers- has quit [Quit: cheers-]
dave0 has joined #forth
dave0 has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
f-a has joined #forth
dave0 has quit [Ping timeout: 256 seconds]
dave0 has quit [Ping timeout: 256 seconds]
mark4 has quit [Read error: Connection reset by peer]
mark4 has quit [Read error: Connection reset by peer]
<veltas>
I'm going to try using Forth with some C libraries, worried about how floats will work but we'll see
<veltas>
I'm going to try using Forth with some C libraries, worried about how floats will work but we'll see
<neuro_sys>
I'm thinking of the floats, I think the format for EVALUATE would require an "e" at the end, so I should think of another way to parse it.
<neuro_sys>
I'm thinking of the floats, I think the format for EVALUATE would require an "e" at the end, so I should think of another way to parse it.
<veltas>
Great minds think alike
<veltas>
Great minds think alike
<neuro_sys>
Haha
<neuro_sys>
Haha
<veltas>
EVALUATE is a terrible idea for security reasons, unless you are completely certain the source is trusted
<veltas>
EVALUATE is a terrible idea for security reasons, unless you are completely certain the source is trusted
<neuro_sys>
I'm doing a toy 3d rasterizer with Forth using fixed point arithmetic, but I want to convert the Blender output to and embed in the code.
<neuro_sys>
I'm doing a toy 3d rasterizer with Forth using fixed point arithmetic, but I want to convert the Blender output to and embed in the code.
<neuro_sys>
I don't particulalry care about security, as long as I convert it to some format I can use it in my code.
<neuro_sys>
I don't particulalry care about security, as long as I convert it to some format I can use it in my code.
<neuro_sys>
The goal is to practice some Forth doing that
<neuro_sys>
The goal is to practice some Forth doing that
<neuro_sys>
I guess I will do it the hard way then, one character at a time.
<neuro_sys>
I guess I will do it the hard way then, one character at a time.
<mark4>
proteus-guy: yes uCurses is in C, it is a full text user interface similar to ncurses but MUCH smaller and in some way MUCh more powerful
<mark4>
proteus-guy: yes uCurses is in C, it is a full text user interface similar to ncurses but MUCH smaller and in some way MUCh more powerful
<mark4>
tho not as reliable across all terminal types
<mark4>
tho not as reliable across all terminal types
<mark4>
yet
<mark4>
yet
<veltas>
neuro_sys: >FLOAT
<veltas>
neuro_sys: >FLOAT
<mark4>
just filed a bug against kde's konsole because hitting backspace returns a 0x7f instead of the 0x08 specified in its terminfo file. the dev said oh thats ok, you can edit your current profile so it returns the right value!
<mark4>
just filed a bug against kde's konsole because hitting backspace returns a 0x7f instead of the 0x08 specified in its terminfo file. the dev said oh thats ok, you can edit your current profile so it returns the right value!
<mark4>
fucking MORON
<mark4>
fucking MORON
<mark4>
me fixing it on MY machine does not make applications compile against my TUI work on every terminal there is. Konsole has incorrect behavior and its the konsole dev that needs to pull his head out and fix it
<mark4>
me fixing it on MY machine does not make applications compile against my TUI work on every terminal there is. Konsole has incorrect behavior and its the konsole dev that needs to pull his head out and fix it
<veltas>
Yeah welcome to bug reports
<veltas>
Yeah welcome to bug reports
<mark4>
its idiot attitudes like him that make ncurses have to have 286552987658972 gigs of duct tape code in them
<mark4>
its idiot attitudes like him that make ncurses have to have 286552987658972 gigs of duct tape code in them
<veltas>
Terminals are overly complicated
<veltas>
Terminals are overly complicated
<mark4>
needlessly
<mark4>
needlessly
<veltas>
Simplify the requirements, output to paper :P
<veltas>
Simplify the requirements, output to paper :P
<proteus-guy>
mark4, uCurses is going to be integrated into your forth?
<proteus-guy>
mark4, uCurses is going to be integrated into your forth?
shmorgle has joined #forth
shmorgle has joined #forth
<mark4>
it was written first in forth years ago but the forth version is a bit rotty right now
<mark4>
it was written first in forth years ago but the forth version is a bit rotty right now
<mark4>
and with the c version i made changes such as the ability to do gray scales and full rgb text colors
<mark4>
and with the c version i made changes such as the ability to do gray scales and full rgb text colors
<mark4>
the intent is to redo the forth version
<mark4>
the intent is to redo the forth version
<proteus-guy>
You mean you will rebuild it again in forth? Or your final version target is the C release?
<proteus-guy>
You mean you will rebuild it again in forth? Or your final version target is the C release?
<joe9>
why not just use 9front or plan9port instead of fighting with curses?
<joe9>
why not just use 9front or plan9port instead of fighting with curses?
<veltas>
joe9: is the 9 in your name a reference to plan9?
<veltas>
joe9: is the 9 in your name a reference to plan9?
<mark4>
no the forth stuff will be redone :)
<mark4>
no the forth stuff will be redone :)
<veltas>
I like rewriting C in Forth too
<veltas>
I like rewriting C in Forth too
<veltas>
People say that Python is good for prototyping before writing in C, well I think C is good for prototyping before writing in Forth :P
<veltas>
People say that Python is good for prototyping before writing in C, well I think C is good for prototyping before writing in Forth :P
<mark4>
actually the prototype was in forth :)
<mark4>
actually the prototype was in forth :)
<kiedtl>
What hidden power do you possess?
<kiedtl>
What hidden power do you possess?
<kiedtl>
pls share
<kiedtl>
pls share
<mark4>
?
<mark4>
?
<kiedtl>
>prototype was in forth
<kiedtl>
>prototype was in forth
<mark4>
i wrote my curses in forth first. im doing the c version now
<mark4>
i wrote my curses in forth first. im doing the c version now
<mark4>
the forth version is a bit old and sufferenig from lack of attention
<mark4>
the forth version is a bit old and sufferenig from lack of attention
<mark4>
the c version has features not present in the forth
<mark4>
the c version has features not present in the forth
<mark4>
finish c... redo forth
<mark4>
finish c... redo forth
hosewiejacke has joined #forth
hosewiejacke has joined #forth
<proteusguy>
mark4, approximately how many lines of forth do you anticipate it'll end up being?
<proteusguy>
mark4, approximately how many lines of forth do you anticipate it'll end up being?
<veltas>
Under 10000 lines of code, everything in perfect balance
<veltas>
Under 10000 lines of code, everything in perfect balance
<mark4>
proteusguy: i dont expect it to take up much more than 8k of code space :)
<mark4>
proteusguy: i dont expect it to take up much more than 8k of code space :)
<mark4>
but the number of lines i couldnt tell you. you could look in x4/src/terminal for an idea :)
<mark4>
but the number of lines i couldnt tell you. you could look in x4/src/terminal for an idea :)
<mark4>
current version is 1412 total lines
<mark4>
current version is 1412 total lines
<mark4>
im not sure if wc -l counts blank lines too
<mark4>
im not sure if wc -l counts blank lines too
<veltas>
Of course it does
<veltas>
Of course it does
<mark4>
:)
<mark4>
:)
<mark4>
sorry slight lie there. that was src/ext/terminal line count
<mark4>
sorry slight lie there. that was src/ext/terminal line count
<mark4>
there is also src/ext/tui
<mark4>
there is also src/ext/tui
<mark4>
1585
<mark4>
1585
<mark4>
so add the two totals for the total total
<mark4>
so add the two totals for the total total
nihilazo has joined #forth
nihilazo has joined #forth
<mark4>
4144 lines of c so far
<mark4>
4144 lines of c so far
<veltas>
cat *.c *.h | sed '/^$/d' | wc -l
<veltas>
cat *.c *.h | sed '/^$/d' | wc -l
fiddlerwoaroof has quit [Quit: Gone.]
fiddlerwoaroof has quit [Quit: Gone.]
fiddlerwoaroof has joined #forth
fiddlerwoaroof has joined #forth
jimt[m] has quit [Ping timeout: 240 seconds]
jimt[m] has quit [Ping timeout: 240 seconds]
patrickg has quit [Ping timeout: 244 seconds]
patrickg has quit [Ping timeout: 244 seconds]
siraben has quit [Ping timeout: 244 seconds]
siraben has quit [Ping timeout: 244 seconds]
tech_exorcist has quit [Ping timeout: 245 seconds]
tech_exorcist has quit [Ping timeout: 245 seconds]
<mark4>
i once saw a cartoon of 3 cavemen saying ugh grrr uhhhhh and then those same characters saing sed, awk, grep
<mark4>
i once saw a cartoon of 3 cavemen saying ugh grrr uhhhhh and then those same characters saing sed, awk, grep
xek has quit [Remote host closed the connection]
xek has quit [Remote host closed the connection]
xek has joined #forth
xek has joined #forth
tech_exorcist has joined #forth
tech_exorcist has joined #forth
<neuro_sys>
Is it possible to define words within words during interpretation? Context: I'm reading a file to count the number of elements, and want to ALLOT that much space in dictionary associated with a word.
<neuro_sys>
Is it possible to define words within words during interpretation? Context: I'm reading a file to count the number of elements, and want to ALLOT that much space in dictionary associated with a word.
<neuro_sys>
My code so far looks like: open-file count-vertices alloc-vbuffer rewind slurp
<neuro_sys>
My code so far looks like: open-file count-vertices alloc-vbuffer rewind slurp
<mark4>
create does> ?
<mark4>
create does> ?
<neuro_sys>
Ah that magic, I knew I'd run into a case where I have to use it :)
<neuro_sys>
Ah that magic, I knew I'd run into a case where I have to use it :)
<mark4>
for example : constant create , does> @ ;
<mark4>
for example : constant create , does> @ ;
jimt[m] has joined #forth
jimt[m] has joined #forth
<veltas>
Is it possible to define words not during interpretation
<veltas>
Is it possible to define words not during interpretation
<veltas>
I guess if it is a MAIN standalone
<veltas>
I guess if it is a MAIN standalone
<veltas>
You sound like DOES> is something you have avoided :P
<veltas>
You sound like DOES> is something you have avoided :P
<neuro_sys>
Hmm right, words are defined during interpretation by switching to compilation with the word : and once finished going back to interpretation with ; right? Just to confirm the basics.
<neuro_sys>
Hmm right, words are defined during interpretation by switching to compilation with the word : and once finished going back to interpretation with ; right? Just to confirm the basics.
<neuro_sys>
Been avoding DOES> so far indeed, now it seems the right time to learn/use it.
<neuro_sys>
Been avoding DOES> so far indeed, now it seems the right time to learn/use it.
<neuro_sys>
I think what I needed was this : alloc-buffer create allot does> here ; and later use it as 10 alloc-buffer buffer1 20 alloc-buffer buffer2
<neuro_sys>
I think what I needed was this : alloc-buffer create allot does> here ; and later use it as 10 alloc-buffer buffer1 20 alloc-buffer buffer2
<neuro_sys>
Woops, not here, but >body
<neuro_sys>
Woops, not here, but >body
siraben has joined #forth
siraben has joined #forth
<neuro_sys>
Actually, I didn't need to use does> for what I needed. I'll share the code once I'm done though for review.
<neuro_sys>
Actually, I didn't need to use does> for what I needed. I'll share the code once I'm done though for review.
<neuro_sys>
I'm sure it's all unidiomatic and far from ideal. At least I'm not using locals any more.
<neuro_sys>
I'm sure it's all unidiomatic and far from ideal. At least I'm not using locals any more.
<neuro_sys>
Or locals as in the special syntax in the later specs.
<neuro_sys>
Or locals as in the special syntax in the later specs.
patrickg has joined #forth
patrickg has joined #forth
jess has quit [Quit: K-Lined]
jess has quit [Quit: K-Lined]
<mark4>
found what i believe is a very VERY serious bug in clang
<mark4>
found what i believe is a very VERY serious bug in clang
<mark4>
i have a function called re_switch() where you pass a character, a function table and a table length
<mark4>
i have a function called re_switch() where you pass a character, a function table and a table length
<mark4>
it scans the table for that character and jumps to the function vecor for that char if its found
<mark4>
it scans the table for that character and jumps to the function vecor for that char if its found
<mark4>
re_switch(&p_codes[0], PCOUNT, next_c())
<mark4>
re_switch(&p_codes[0], PCOUNT, next_c())
<mark4>
here is my one invocation of that public function thats going to be exported for lib users to use if they chose
<mark4>
here is my one invocation of that public function thats going to be exported for lib users to use if they chose
<mark4>
oopts cant
<mark4>
oopts cant
<mark4>
because here is what that one call is compiled down to
<mark4>
because here is what that one call is compiled down to
<mark4>
.text:00000000002057E1 jmp short loc_2057AE
<mark4>
.text:00000000002057D4 call next_c
<mark4>
.text:00000000002057DC call re_switch
<mark4>
.text:00000000002057DC call re_switch
<mark4>
.text:00000000002057D9 movsx edi, al ; s
<mark4>
.text:00000000002057E1 jmp short loc_2057AE
<mark4>
mp referemce to p_table or PCOUNT
<mark4>
mp referemce to p_table or PCOUNT
<mark4>
because BOTH of those are now built into the now single purpose function
<mark4>
because BOTH of those are now built into the now single purpose function
<mark4>
no referene to...
<mark4>
no referene to...
<patrickg>
is it a static function with this as its only user, or an LTO build to an executable (in both cases the compiler could do that until you add another invocation that passes different arguments)
<patrickg>
is it a static function with this as its only user, or an LTO build to an executable (in both cases the compiler could do that until you add another invocation that passes different arguments)
<neuro_sys>
I'm pretty sure this is NOT how it should be done, but anyway, this's how it turned out.
<neuro_sys>
I'm pretty sure this is NOT how it should be done, but anyway, this's how it turned out.
hosewiejacke has quit [Remote host closed the connection]
hosewiejacke has quit [Remote host closed the connection]
gravicappa has quit [Ping timeout: 260 seconds]
gravicappa has quit [Ping timeout: 260 seconds]
cantstanya has quit [Remote host closed the connection]
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #forth
cantstanya has joined #forth
<KipIngram>
So, if anyone is interested I have a fairly tidy and fully debugged implementation of QUERY and EXPECT I put together for the re-write of my system I'm working on.
<KipIngram>
So, if anyone is interested I have a fairly tidy and fully debugged implementation of QUERY and EXPECT I put together for the re-write of my system I'm working on.
<KipIngram>
It uses some special features of my system, like conditional and multi-level returns.
<KipIngram>
It uses some special features of my system, like conditional and multi-level returns.
<KipIngram>
Also, a . at the beginning of a word generally means the word keeps one more item on the stack than you'd expect.
<KipIngram>
Also, a . at the beginning of a word generally means the word keeps one more item on the stack than you'd expect.
<KipIngram>
So .emit for example doesn't drop the character tha tit outputs. Etc.
<KipIngram>
So .emit for example doesn't drop the character tha tit outputs. Etc.
<KipIngram>
.: also indicates a special feature of my system - it defines a "temporary word." After defining a bunch of those, and using them to build actual visible definitions, I can execute .wipe and they're all removed from the dictionary. Keeps the namespace tidy.
<KipIngram>
.: also indicates a special feature of my system - it defines a "temporary word." After defining a bunch of those, and using them to build actual visible definitions, I can execute .wipe and they're all removed from the dictionary. Keeps the namespace tidy.
<KipIngram>
You could certainly do that equally well with vocabularies.
<KipIngram>
You could certainly do that equally well with vocabularies.
<KipIngram>
Just as a quick example, .!=; is a conditional return word. It does != (not equal), which ordinarily would consume two arguments. But it has a . at the start, so it only consumes one.
<KipIngram>
Just as a quick example, .!=; is a conditional return word. It does != (not equal), which ordinarily would consume two arguments. But it has a . at the start, so it only consumes one.
<KipIngram>
In this case that means it consumes the ascii code I put on that to compare to, but doesn't consume the keyboard-entered char.
<KipIngram>
In this case that means it consumes the ascii code I put on that to compare to, but doesn't consume the keyboard-entered char.
<KipIngram>
And the ; at the end means the return is taken if the != operation is true.
<KipIngram>
And the ; at the end means the return is taken if the != operation is true.
<KipIngram>
I've found those conditional returns to be very valuable - my definitions definitely became shorter when I started using them.
<KipIngram>
I've found those conditional returns to be very valuable - my definitions definitely became shorter when I started using them.
<KipIngram>
I recommend them.
<KipIngram>
I recommend them.
<KipIngram>
;; returns two levels, of course.
<KipIngram>
;; returns two levels, of course.
<KipIngram>
s0 s1 s2 s3 access stack variables relative to a "frame register" that my system contains. { saves the current frame register on the return stack. } retrieves it, sets the stack pointer back to what it was when { was issued, and then drops the number of arguments specified. In this case 4.
<KipIngram>
s0 s1 s2 s3 access stack variables relative to a "frame register" that my system contains. { saves the current frame register on the return stack. } retrieves it, sets the stack pointer back to what it was when { was issued, and then drops the number of arguments specified. In this case 4.
<KipIngram>
So query puts an address and a max count on the stack.
<KipIngram>
So query puts an address and a max count on the stack.
<KipIngram>
Expect adds two 0's that represent string size and cursor position within the string, and then frames up those four things so that s3 - s0 gets the address of those stack cells for standard operations.
<KipIngram>
Expect adds two 0's that represent string size and cursor position within the string, and then frames up those four things so that s3 - s0 gets the address of those stack cells for standard operations.
<KipIngram>
Very handy in a situation like this where you have several important pieces of information you need access to. Here we have a buffer address, a max string length, a current string length, a cursor position, and sometimes also an ASCII code from the keyboard. That's a lot to juggle without some sort of special stack access.
<KipIngram>
Very handy in a situation like this where you have several important pieces of information you need access to. Here we have a buffer address, a max string length, a current string length, a cursor position, and sometimes also an ASCII code from the keyboard. That's a lot to juggle without some sort of special stack access.
<KipIngram>
If you pick through it you'll see how the conditional returns and the multi-level returns let construct control structures that run up and down in the call stack. It's like an extra "dimension" to use in building those control structures.
<KipIngram>
If you pick through it you'll see how the conditional returns and the multi-level returns let construct control structures that run up and down in the call stack. It's like an extra "dimension" to use in building those control structures.
<KipIngram>
I may someday add the ability to bind the sn frame variables to names specified in a ( ... ) comment, but that would all be handled at compile time. I don't find it that hard to remember what I have in the various stack cells, and I don't usually use stack effect comments anyway, so... maybe / maybe not on that.
<KipIngram>
I may someday add the ability to bind the sn frame variables to names specified in a ( ... ) comment, but that would all be handled at compile time. I don't find it that hard to remember what I have in the various stack cells, and I don't usually use stack effect comments anyway, so... maybe / maybe not on that.
<KipIngram>
This supports backspace, cursor left, cursor right, beginning of line, and end of line control keys.
<KipIngram>
This supports backspace, cursor left, cursor right, beginning of line, and end of line control keys.
<KipIngram>
It would be easy to add in cursor up and cursor down to add a command history - I've done that in my recent syste, but it's not reflected here.
<KipIngram>
It would be easy to add in cursor up and cursor down to add a command history - I've done that in my recent syste, but it's not reflected here.
<KipIngram>
The "read" word is basically an infinite loop - it runs quit? each character, and that will do a double return on Enter - breaking the loop.
<KipIngram>
The "read" word is basically an infinite loop - it runs quit? each character, and that will do a double return on Enter - breaking the loop.
<KipIngram>
Oh, and "me" in my system "me" is a stand-in for recursively calling the word it's in. I could have just put "read" after "insert" in there. However, the "me" mechanism supports conditional looping too; like the 0=me word loops back to the start if the top of stack is 0. And consumes the top of stack, since there's no .
<KipIngram>
Oh, and "me" in my system "me" is a stand-in for recursively calling the word it's in. I could have just put "read" after "insert" in there. However, the "me" mechanism supports conditional looping too; like the 0=me word loops back to the start if the top of stack is 0. And consumes the top of stack, since there's no .
<KipIngram>
I have [ at the end of a few of those words because they end in me. I don't need (;) - I just need to get out of compile mode.
<KipIngram>
I have [ at the end of a few of those words because they end in me. I don't need (;) - I just need to get out of compile mode.
<KipIngram>
I suppose I could still put ; and tail recursion would optimize it away.
<KipIngram>
I suppose I could still put ; and tail recursion would optimize it away.
<KipIngram>
I may confirm that and change it. Just for readability.
<KipIngram>
I may confirm that and change it. Just for readability.
<KipIngram>
The thing is, though, "me" is not a compiled Forth word. It's a primitive.
<KipIngram>
The thing is, though, "me" is not a compiled Forth word. It's a primitive.
<KipIngram>
So that might not work.
<KipIngram>
So that might not work.
<KipIngram>
Definitely wouldn't work.
<KipIngram>
Definitely wouldn't work.
<KipIngram>
This relies on the keyboard being in "raw" mode, and the enter key (which I think normally returns ^j has been flagged to return ^m instead.
<KipIngram>
This relies on the keyboard being in "raw" mode, and the enter key (which I think normally returns ^j has been flagged to return ^m instead.
<KipIngram>
But you just can't really implement standard Forth console behavior using a cooked console.
<KipIngram>
But you just can't really implement standard Forth console behavior using a cooked console.
<KipIngram>
Once you call for a line of input, you don't get control back until the user hits Enter.
<KipIngram>
Once you call for a line of input, you don't get control back until the user hits Enter.
<KipIngram>
It ignores all control keys except for the ones explicitly checked for.
<KipIngram>
It ignores all control keys except for the ones explicitly checked for.
<KipIngram>
It does all the right things, though - ignores backspace and cursor left if the cursor is at position 0, ignores cursor right if it's at the other end, and stops taking anything if you reach the max size.
<KipIngram>
It does all the right things, though - ignores backspace and cursor left if the cursor is at position 0, ignores cursor right if it's at the other end, and stops taking anything if you reach the max size.
<KipIngram>
It does put a null at the end, so I probably should 1- max before framing up, to make sure a spot is left for the null.
<KipIngram>
It does put a null at the end, so I probably should 1- max before framing up, to make sure a spot is left for the null.
<mark4>
KipIngram did you not just copy the L&P version from F83 :)
<mark4>
KipIngram did you not just copy the L&P version from F83 :)
<KipIngram>
No, I've never looked at that.
<KipIngram>
No, I've never looked at that.
<KipIngram>
But it wouldn't surprise me to find it's similar to something soemone else did.
<KipIngram>
But it wouldn't surprise me to find it's similar to something soemone else did.
<mark4>
laxen and perry wrote the original 83 standards compliant forth for dos :)
<mark4>
laxen and perry wrote the original 83 standards compliant forth for dos :)
<mark4>
pretty much everyone copied them from there :)
<mark4>
pretty much everyone copied them from there :)
<KipIngram>
Nah, not me.
<KipIngram>
Nah, not me.
<mark4>
including tom zimmer for FPC for dos and ME for x4 etc :)
<mark4>
including tom zimmer for FPC for dos and ME for x4 etc :)
<KipIngram>
I just started with nasm and a blank slate - this is implemented in assembly.
<KipIngram>
I just started with nasm and a blank slate - this is implemented in assembly.
<mark4>
their expect definition does not really allow for line editing other than backspace :/
<mark4>
their expect definition does not really allow for line editing other than backspace :/
<KipIngram>
But hey, you should have seen the monstrosity that was my first Forth, which I wrote before gettinng a copy McCabe's "Forth Fundamentals."
<KipIngram>
But hey, you should have seen the monstrosity that was my first Forth, which I wrote before gettinng a copy McCabe's "Forth Fundamentals."
<KipIngram>
I didn't' really know how a system was supposed to work under the hood, so mine was nowhere close to elegant.
<KipIngram>
I didn't' really know how a system was supposed to work under the hood, so mine was nowhere close to elegant.
<KipIngram>
I read McCabe and was like "Holy shit - that is CLEAN."
<KipIngram>
I read McCabe and was like "Holy shit - that is CLEAN."
<KipIngram>
So I didn't copy anyone's source code, but I copied a lot of exiting ideas.
<KipIngram>
So I didn't copy anyone's source code, but I copied a lot of exiting ideas.
<mark4>
patrickg i was building the "application" with -flto yes and that is what was causing the not really a bug
<mark4>
patrickg i was building the "application" with -flto yes and that is what was causing the not really a bug
<mark4>
converting the project into a library fixed that issue
<mark4>
converting the project into a library fixed that issue
<mark4>
thats the best way
<mark4>
thats the best way
<mark4>
i just copied the FPC code pretty much verbatum out of lazyness lol and being used to the way it works
<mark4>
i just copied the FPC code pretty much verbatum out of lazyness lol and being used to the way it works
<mark4>
query is usually just : query tib XXX expect ;
<mark4>
query is usually just : query tib XXX expect ;
<mark4>
in dos xxx would be 80 :)
<mark4>
in dos xxx would be 80 :)
<KipIngram>
Sure. What else would it be, you know? :-)
<KipIngram>
Sure. What else would it be, you know? :-)
<mark4>
heh
<mark4>
heh
<KipIngram>
It's only purpose is to just wrapper expect for use as system input.
<KipIngram>
It's only purpose is to just wrapper expect for use as system input.
<mark4>
ya
<mark4>
ya
<mark4>
you can also do foo-buffer 1234 expect
<mark4>
you can also do foo-buffer 1234 expect
<mark4>
but i never did lol
<mark4>
but i never did lol
<KipIngram>
My existing prior effort here was also in nasm, but I got infaturated with some of Chuck's "sourceless programming" ideas and tried to implement them, and eventually the memory management got more involved than I like, and then something changed in the MacOS build tool chain and it's not quite working right now. So this is a do-over, intent on keeping things much simpler. I've got a nice set of nasm macros
<KipIngram>
My existing prior effort here was also in nasm, but I got infaturated with some of Chuck's "sourceless programming" ideas and tried to implement them, and eventually the memory management got more involved than I like, and then something changed in the MacOS build tool chain and it's not quite working right now. So this is a do-over, intent on keeping things much simpler. I've got a nice set of nasm macros
<KipIngram>
that handle all the dictionary building part. Headers and bodies are in separate sections. When it starts up it allocates two blocks of RAM using system calls and copies those sections into them, and then it abandons the original image. So there's no more bother with write permissions in the code space and things like that.
<KipIngram>
that handle all the dictionary building part. Headers and bodies are in separate sections. When it starts up it allocates two blocks of RAM using system calls and copies those sections into them, and then it abandons the original image. So there's no more bother with write permissions in the code space and things like that.
<KipIngram>
I do have to juggle two HERE's, but I'll manage.
<KipIngram>
I do have to juggle two HERE's, but I'll manage.
<KipIngram>
It puts the CFA and PFA portions of definitions up with the name strings, so declaring a new symbol in the middle of a definition doesn't jam anything into the middle of the definition address list. Let's me have multiple entry points, a la
<KipIngram>
It puts the CFA and PFA portions of definitions up with the name strings, so declaring a new symbol in the middle of a definition doesn't jam anything into the middle of the definition address list. Let's me have multiple entry points, a la
<KipIngram>
: foo ... ... ... :bar ... ... ;
<KipIngram>
: foo ... ... ... :bar ... ... ;
<KipIngram>
That was really the main reason I didn't just do a standard FIG structure.
<KipIngram>
That was really the main reason I didn't just do a standard FIG structure.
<KipIngram>
I'll pastebin those macros for the dictionary and share them later.
<KipIngram>
I'll pastebin those macros for the dictionary and share them later.
<KipIngram>
Lets definitions in the assembly look like this:
<KipIngram>
Lets definitions in the assembly look like this:
<KipIngram>
;;; .: quit? 13 .!=; >end ;;
<KipIngram>
;;; .: quit? 13 .!=; >end ;;
<KipIngram>
def "quit?", quitq, COVERT
<KipIngram>
def "quit?", quitq, COVERT
<KipIngram>
run plit, 13+do, dnesem, gtend, dosem2
<KipIngram>
run plit, 13+do, dnesem, gtend, dosem2
<KipIngram>
Top two bits of the count byte are used for things - 0x80 is the immediate flag and 0x40 is the "temporary word" flag. In my last system I actually put the headers of temporary words into temporaryily allocated RAM, and got rid of them when I was done. I blew that sophistication off - this time the headers will stay but that bit will get set and the search will just pass over them. Much simpler.
<KipIngram>
Top two bits of the count byte are used for things - 0x80 is the immediate flag and 0x40 is the "temporary word" flag. In my last system I actually put the headers of temporary words into temporaryily allocated RAM, and got rid of them when I was done. I blew that sophistication off - this time the headers will stay but that bit will get set and the search will just pass over them. Much simpler.
<KipIngram>
It's just insane these days to get all wound up over saving RAM. :-(
<KipIngram>
It's just insane these days to get all wound up over saving RAM. :-(
<KipIngram>
I get a little anal about such stuff at times.
<KipIngram>
I get a little anal about such stuff at times.
<mark4>
aha so headerless
<mark4>
aha so headerless
<KipIngram>
I mentioned copying things around - this is all 100% relocatable. Put it anywhere, and set a register to the base address. Everything that hapens is relative to one of those two registers.
<KipIngram>
I mentioned copying things around - this is all 100% relocatable. Put it anywhere, and set a register to the base address. Everything that hapens is relative to one of those two registers.
<KipIngram>
The previous one, yes.
<KipIngram>
The previous one, yes.
<KipIngram>
It would put the CFA and PFA in the main header position, but the name was off in a temporary buffer.
<KipIngram>
It would put the CFA and PFA in the main header position, but the name was off in a temporary buffer.
<mark4>
right
<mark4>
right
<KipIngram>
It actually worked quite well. But I'm not going to introduce dynamic memmory into the system so early this time.
<KipIngram>
It actually worked quite well. But I'm not going to introduce dynamic memmory into the system so early this time.
<mark4>
in x4 what i do is flip dp and hp with headerless versions of them that i initialize to 16k above hhere
<mark4>
in x4 what i do is flip dp and hp with headerless versions of them that i initialize to 16k above hhere
<mark4>
i can flip flop between making headerful and headerless words and behead later
<mark4>
i can flip flop between making headerful and headerless words and behead later
<KipIngram>
With the other one I actually compiled new stuff into dynamic memory. I could use quite small pages, and if one filled up I'd get a new one.
<KipIngram>
With the other one I actually compiled new stuff into dynamic memory. I could use quite small pages, and if one filled up I'd get a new one.
<KipIngram>
And that worked - a definition could come to the end of a page and would jump off to some other page to continue.
<KipIngram>
And that worked - a definition could come to the end of a page and would jump off to some other page to continue.
<KipIngram>
It's all pleasing when something like that works, but all that complexity gradually adds up.
<KipIngram>
It's all pleasing when something like that works, but all that complexity gradually adds up.
<neuro_sys>
Before I try to read through it all, what's query and expet in general?
<neuro_sys>
Before I try to read through it all, what's query and expet in general?
<mark4>
got a new battery for my mouse, need to crack open the mouse and take the old one out and solder its connector onto my new battery
<mark4>
got a new battery for my mouse, need to crack open the mouse and take the old one out and solder its connector onto my new battery
<mark4>
going for 600mha to 800 but did not know the 1k would have fit in there too lol
<mark4>
going for 600mha to 800 but did not know the 1k would have fit in there too lol
<mark4>
get taht one next time
<mark4>
get taht one next time
<KipIngram>
Expect takes an address and a max size on the stack and manages the keyboard entry of a string of up to that length into the buffer.
<KipIngram>
Expect takes an address and a max size on the stack and manages the keyboard entry of a string of up to that length into the buffer.
<KipIngram>
Query just specifies the standard console input buffer and calls expect - it's used exclusively in the outer interpreter loop.
<KipIngram>
Query just specifies the standard console input buffer and calls expect - it's used exclusively in the outer interpreter loop.
<KipIngram>
Expect, though, is general purpose for anytime you need a keyboard string.
<KipIngram>
Expect, though, is general purpose for anytime you need a keyboard string.
<KipIngram>
With a cooked keyboard, just getting any keyboard input is basically "expect," provided off in the OS.
<KipIngram>
With a cooked keyboard, just getting any keyboard input is basically "expect," provided off in the OS.
<KipIngram>
Without modifying the termios you can't read a single keystroke from the console.
<KipIngram>
Without modifying the termios you can't read a single keystroke from the console.
<KipIngram>
So this code is doing all the stuff the OS would do for you on a cooked keyboard. Manages the cursoring around, opening up space in an existing string to insert a char into the middle of it, and so on.
<KipIngram>
So this code is doing all the stuff the OS would do for you on a cooked keyboard. Manages the cursoring around, opening up space in an existing string to insert a char into the middle of it, and so on.
<KipIngram>
It doesn't use or support the standard cursor keys.
<KipIngram>
It doesn't use or support the standard cursor keys.
<KipIngram>
It uses vim keys.
<KipIngram>
It uses vim keys.
<KipIngram>
^h for cursor left, ^l for cursor right. ^p for end of line, ^o for start of line.
<KipIngram>
^h for cursor left, ^l for cursor right. ^p for end of line, ^o for start of line.
<KipIngram>
As it stands now, if you hit one of the cursor keys, it would ignore the Escape and then take what followed as though you'd typed it.
<KipIngram>
As it stands now, if you hit one of the cursor keys, it would ignore the Escape and then take what followed as though you'd typed it.
<KipIngram>
Apparently the cursor keys are <esc>[A through <esc>[D.
<KipIngram>
Apparently the cursor keys are <esc>[A through <esc>[D.
<KipIngram>
I really wish that the people who devised all this way back when had chose something other than <esc> for starting off those strings
<KipIngram>
I really wish that the people who devised all this way back when had chose something other than <esc> for starting off those strings
<KipIngram>
Something, anything, that you can't also make yourself as an independent keystroke.
<KipIngram>
Something, anything, that you can't also make yourself as an independent keystroke.
<neuro_sys>
I see. I'm curious why forth-standard.org/search doesn't have both words, but gforth does.
<neuro_sys>
I see. I'm curious why forth-standard.org/search doesn't have both words, but gforth does.
<KipIngram>
Because if you read <esc> from the keyboard, you can't tell if that was pressing the <esc> key and that's all there is, or if it's an extended key and there's some unknown number of bytes after that to expect.
<KipIngram>
Because if you read <esc> from the keyboard, you can't tell if that was pressing the <esc> key and that's all there is, or if it's an extended key and there's some unknown number of bytes after that to expect.
<neuro_sys>
So they are not standard words, but present in all/most Forths?
<neuro_sys>
So they are not standard words, but present in all/most Forths?
<KipIngram>
Oh, well, QUERY does very little.
<KipIngram>
Oh, well, QUERY does very little.
<KipIngram>
You could easily dispense with it and just use <address> <max> EXPECT instead.
<KipIngram>
You could easily dispense with it and just use <address> <max> EXPECT instead.
<KipIngram>
I don't think QUERY is in the standard.
<KipIngram>
I don't think QUERY is in the standard.
<KipIngram>
It was in the old FIG Forths though.
<KipIngram>
It was in the old FIG Forths though.
<KipIngram>
Like I said, it barely passes as needed.
<KipIngram>
Like I said, it barely passes as needed.
<neuro_sys>
And if I understand correctly, your Forth solution is useful for platforms where the OS does not provide a handy call for that?
<neuro_sys>
And if I understand correctly, your Forth solution is useful for platforms where the OS does not provide a handy call for that?
<KipIngram>
Just slightly shortens some definition in the outer interpreter.
<KipIngram>
Just slightly shortens some definition in the outer interpreter.
<neuro_sys>
EXPECT is not on that website either for some reason.
<neuro_sys>
EXPECT is not on that website either for some reason.
<KipIngram>
Right. This system doesn't even use a c library.
<KipIngram>
Right. This system doesn't even use a c library.
<KipIngram>
It does system calls directly to the OS.
<KipIngram>
It does system calls directly to the OS.
<KipIngram>
syscall 3 is read file, and 0 for the file makes it the keyboard.
<KipIngram>
syscall 3 is read file, and 0 for the file makes it the keyboard.
<KipIngram>
syscall 4 writes.
<KipIngram>
syscall 4 writes.
<KipIngram>
file #1 is output.
<KipIngram>
file #1 is output.
<KipIngram>
file 0 == stdin
<KipIngram>
file 0 == stdin
<KipIngram>
file 1 == stdout
<KipIngram>
file 1 == stdout
<KipIngram>
syscall 54 is ioctl
<KipIngram>
syscall 54 is ioctl
<KipIngram>
I think I'm using read, write, ioctl, and allocate memory syscalls, and nothing else at all external to what I've written.
<KipIngram>
I think I'm using read, write, ioctl, and allocate memory syscalls, and nothing else at all external to what I've written.
<KipIngram>
It'd definitely intended to be something I could port to some bare metal project I do in the future.
<KipIngram>
It'd definitely intended to be something I could port to some bare metal project I do in the future.
<KipIngram>
Last time the primitives were my base layer, and would need to be rewritten for a port.
<KipIngram>
Last time the primitives were my base layer, and would need to be rewritten for a port.
<KipIngram>
This time I'm trying to define a "virtual machine layer" - I implement virtual instructions for that machine using macros, and then write the primitives using those.
<KipIngram>
This time I'm trying to define a "virtual machine layer" - I implement virtual instructions for that machine using macros, and then write the primitives using those.
<KipIngram>
So that those virtual instructions should be the only things I have to port to a new platform.
<KipIngram>
So that those virtual instructions should be the only things I have to port to a new platform.
<KipIngram>
There should be fewer of them than there are primitives,.
<KipIngram>
There should be fewer of them than there are primitives,.
<KipIngram>
But I'm not trying to minimize the number of virtual instructions. I could, but I'd wind up with a poorly performing system.
<KipIngram>
But I'm not trying to minimize the number of virtual instructions. I could, but I'd wind up with a poorly performing system.
<KipIngram>
I'm going for a set of instructions that's relatively easy to port, but still lets me use near optimal machine code on at least x86 and ARM.
<KipIngram>
I'm going for a set of instructions that's relatively easy to port, but still lets me use near optimal machine code on at least x86 and ARM.
<remexre>
are you doing a simple interpreter, or compiling/fusing the virtual instructions?
<remexre>
are you doing a simple interpreter, or compiling/fusing the virtual instructions?
<KipIngram>
I'm not sure what you mean. Once I have it all working, I do want to put enough assembly support in Forth to allow the thing to rebuild itself.
<KipIngram>
I'm not sure what you mean. Once I have it all working, I do want to put enough assembly support in Forth to allow the thing to rebuild itself.
<KipIngram>
Then leave nasm behind.
<KipIngram>
Then leave nasm behind.
<KipIngram>
The virtual instructions are nasm macros. So a list of virtual instructions just becomes a normal primitive. There's no extra "call" in there for that layer.
<KipIngram>
The virtual instructions are nasm macros. So a list of virtual instructions just becomes a normal primitive. There's no extra "call" in there for that layer.
<KipIngram>
It's just a different way of writing the same machine code primitives.
<KipIngram>
It's just a different way of writing the same machine code primitives.
<remexre>
ah, I thought you meant something like
<remexre>
ah, I thought you meant something like
<remexre>
being an STC forth + having inline machine code, but that's for a virtual machine
<remexre>
being an STC forth + having inline machine code, but that's for a virtual machine
<remexre>
and then either emulating or compiling that to the real target machine code
<remexre>
and then either emulating or compiling that to the real target machine code
<KipIngram>
Right. No, this is just a straight up implementation. Once it can rebuild itself, though, I ought to be able to use it to compile an image for a different platform.
<KipIngram>
Right. No, this is just a straight up implementation. Once it can rebuild itself, though, I ought to be able to use it to compile an image for a different platform.
<KipIngram>
Like for instance, I have a macro "getd". I can write
<KipIngram>
Like for instance, I have a macro "getd". I can write
<KipIngram>
getd rrTOS, rrSP
<KipIngram>
getd rrTOS, rrSP
<KipIngram>
annd that becomes
<KipIngram>
annd that becomes
<KipIngram>
mov rcx, [r12]
<KipIngram>
mov rcx, [r12]
<KipIngram>
the macro "knows" what I'm using the registers for, and so on. The only purpose of this layer is to allow a smaller set of things to re-impilement on a port.
<KipIngram>
the macro "knows" what I'm using the registers for, and so on. The only purpose of this layer is to allow a smaller set of things to re-impilement on a port.
<KipIngram>
This system and the other nasm system has 64-bit stacks and "basic data." But 32-bit system internals. The cells in a definition that species a word are 32 bits each.
<KipIngram>
This system and the other nasm system has 64-bit stacks and "basic data." But 32-bit system internals. The cells in a definition that species a word are 32 bits each.
<KipIngram>
That was just to reduce size.
<KipIngram>
That was just to reduce size.
<KipIngram>
I just saw no need to be able to have a system bigger than 4GB. :-)
<KipIngram>
I just saw no need to be able to have a system bigger than 4GB. :-)