<lispmacs[work]>
joe9: I am not familiar with it, but am curious. Can you send me a link to felix forth?
<joe9>
google github, 8l/ff
<joe9>
it is simple enough to understand. the beauty of simplicity.
jyf has joined #forth
astrid has quit [Quit: changing host]
astrid has joined #forth
f-a has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
Gromboli has joined #forth
crest_ has quit [Ping timeout: 260 seconds]
crest has joined #forth
f-a has quit [Quit: leaving]
gravicappa has joined #forth
dave0 has joined #forth
sts-q has quit [Ping timeout: 260 seconds]
sts-q has joined #forth
foucist has joined #forth
actuallybatman has joined #forth
actuallybatman has quit [Ping timeout: 245 seconds]
foucist has quit [Quit: leaving]
ecraven has quit [Ping timeout: 272 seconds]
ecraven has joined #forth
hosewiejacke has joined #forth
dnm_ has joined #forth
mjl_ has joined #forth
a3f has joined #forth
jess has quit [*.net *.split]
mjl has quit [*.net *.split]
a3f_ has quit [*.net *.split]
dnm has quit [*.net *.split]
tangentstorm has quit [*.net *.split]
krjst has quit [*.net *.split]
mjl_ is now known as mjl
dnm_ is now known as dnm
jess has joined #forth
xek has joined #forth
shmorgle has quit [Ping timeout: 264 seconds]
f-a has joined #forth
hosewiejacke has quit [Ping timeout: 245 seconds]
hosewiejacke has joined #forth
f-a_ has joined #forth
f-a has quit [Ping timeout: 260 seconds]
f-a_ has quit [Client Quit]
f-a has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
f-a has quit [Quit: leaving]
hosewiejacke has quit [Ping timeout: 245 seconds]
elioat has joined #forth
<mark4>
well foucist came by and added me to the +o list, cm has not responded to my invite so... guess we should put it to a vote. should we redirect #forth to ##forth?
<mark4>
founder status is not important to me
<boru>
Well, it's only to conform to freenode's silly channel naming convention, right? Is there any other motivation?
<mark4>
newp
<mark4>
and i dont like their convention but... this is THEIR network lol
<boru>
Sure, but it seems utterly redundant.
<mark4>
redundantly redundant even :)
<boru>
Quite.
<boru>
I don't think a channel forward will really effect anyone other than if they have set +Q
<mark4>
what is +Q ?
<boru>
A user mode to not be forwarded on this net.
<mark4>
oh
<boru>
I usually set it, because I find forwards to be annoying. Most often because of the silly forward critera some chanops set.
<boru>
e.g. channel join count, whereas other mechanics for controlling that exist.
<boru>
But to avoid that, all one has to do is set their autojoin to the new channel rather than the old one.
<boru>
So, no big deal, I suppose.
<mark4>
its the people who are in here that are important
<boru>
I'm mostly a passerby, so my opinion doesn't really carry any weight here.
<mark4>
if you are active your opinion carries :)
<mark4>
dont care about the opinion of the bots :)
<elioat>
beep boop
dave0 has quit [Quit: dave's not here]
<inode>
if they aren't going to force you to change the channel name, why bother?
<mark4>
oh no! frys electronics is shutting down its entire operation lol
<mark4>
what ever will we do!
f-a has joined #forth
<joe9>
I am trying to understand what this instruction does: inc dword [ebp - 8] -- nasm
<joe9>
This is used by loop of forth
<joe9>
I understand that [ebp - 8] gets the contents of the location at ebp - 8.
<joe9>
I could not figure out what the dword there does.
<joe9>
does it increment 2 words (32 bits) whose value is at ebp-8?
<f-a>
uhhhh
<f-a>
I suspect this has to do some some kind of stack and/or pointer
<f-a>
but I cannot read nasm, so…
<mark4>
im guessing that EBP is the return stack pointer
<mark4>
im also guessing that the forth you are looking at is 64 bits and that the definition for I adds [ebp] and [ebp+8]
<mark4>
oh im ALSO guessing that opcode is in the (loop) definition :)
<f-a>
ok
<mark4>
so thats incrementing the loop index which will cause an overflow flag set when the loop completes
<joe9>
I like it as it is simple enough to port/understand.
<mark4>
but it is certainly not as optimal as the way laxen and perry did it in F83 which was coppied by tom zimmer for fpc which was copied by me in x4/x64 }:)
<mark4>
next it ADDS not subtracts (my bad) 0x8000000 to the loop start index and then subtracts that from the end index
<joe9>
It looks like it puts the start index and then end index to the return stack
<mark4>
that "fudges" the loop indicies
<mark4>
it then pushes both of the fudged loop indicies
<mark4>
what this means is DO works for both loop and +loop and for positive and negative increments
hosewiejacke has joined #forth
<joe9>
oh, sorry. end first then start into the return stack.
<joe9>
why the subtract of 0x8000000?
<mark4>
magic :)
<mark4>
math magic
<joe9>
to remove negative numbers?
<joe9>
absolute values?
<mark4>
what that does is the CURRENT index thats pushed to the top of the return tack will cause a stack overflow when the index reaches the limit
<mark4>
adding 0x800000 makes it negative but then subtracing the end index from it makes it positive again
<mark4>
it will be equal to 0x80000000 MINUS the number of required itterations
<mark4>
understand? :)
shmorgle has joined #forth
<joe9>
so, the reutrn stack would be endindex, startindex, and the address to return from loop to, correct?
<mark4>
it will then be incremented back up to 0x800000 which is an overflow
<mark4>
or it will be decremented back down to 0x800000 and ... underflow :)
<joe9>
I think I get it. I will have to work it out on paper slowly. Thanks so much.
<mark4>
the return stack has the current index not start index. and fundged
<mark4>
to get the actual index value you add both of the fudged indicies
<mark4>
add [ebp] to [ebp +4]
<mark4>
its not my code - i think it was laxen and perry who implemented it origainlly when they implemented the first 83 standard forth
<mark4>
tho... it may pre-date them too
<mark4>
btw, the xchg ebp, esp is so i can access the return stacks with push/pop opcodes
<mark4>
instead of fetches and stores
<mark4>
ebp is the return stack, esp is the parameter stack
<joe9>
yes, thanks.
<joe9>
mark4, It has been a enlightening experience working with forth code. Thanks for sharing your work to guide noobs like me.
<mark4>
i was a noob when i started writing x4 really
<mark4>
i knew how to USE forth just not how to implement it :)
hosewiejacke has quit [Ping timeout: 245 seconds]
Zarutian_HTC has quit [Ping timeout: 260 seconds]
<joe9>
mark4, how long did it take you to get comfortable using forth?
<mark4>
actually not a long time because my brain was not yet poluted with things like C :)
<mark4>
i was a pure asm coder first
Zarutian_HTC has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 245 seconds]
boru has quit []
boru has joined #forth
rixard has joined #forth
Zarutian_HTC has quit [Ping timeout: 260 seconds]
hosewiejacke has joined #forth
<nihilazo>
been thinking about my kinda dumb tic-80 forth idea and I'm kinda confused about it, because tic-80 is one weird thing
<nihilazo>
it has memory, like a real computer, that can be addressed and read/written from by the user like a real computer
<nihilazo>
but also, it's built on a lua VM, so either I build the first bits of forth stuff in lua/fennel using lua/fennel primitives or build them in lua/fennel reading/writing the tic-80's memory directly
<nihilazo>
I've no idea how I'd do that for the best
<elioat>
nihilazo I think you may have better luck with the PICO-8, from my limited experience it has a cleaner distinction between VM and its own runtime
<nihilazo>
I'm not such a fan of pico-8, not really sure why tbh
<nihilazo>
I guess I'm more used to tic-80
hosewiejacke has quit [Client Quit]
<elioat>
that is legit
<nihilazo>
(and having fennel support already)
<elioat>
yeah, if I could have a legit scheme in pico-8 I don't think I'd ever use anything else
<elioat>
fennel is fun but makes my head spin because I'm too addicted to cons and cdr
<nihilazo>
fennel isn't really a legit scheme but it's nicer than lua
<nihilazo>
imo
<nihilazo>
I'm writing a bad solitare game in it right now, just because
<elioat>
oh fun!
<nihilazo>
it's one of my...three ongoing useless proejcts?
<nihilazo>
lol
<nihilazo>
but fun
gravicappa has quit [Ping timeout: 246 seconds]
gravicappa has joined #forth
lispmacs[work] has quit [Remote host closed the connection]
<veltas>
joe9: When you add 0x80000000 before doing an operation, it's usually because you want a flag/status from unsigned arithmetic to work for signed arithmetic
<veltas>
For example, if I want to compare the size of two numbers, I can add 0x80000000 to each to make the signed range [-0x80000000,0x7FFFFFFF] into the unsigned range [0x00000000,0xFFFFFFFF]
<veltas>
Then if there is a borrow when subtracting one number from the other as unsigned numbers, I know that one is 'larger' than the other on the signed numberline too
<mark4>
how the BLEEP do you store a utf8 string in c. char foo[] = "foo";
<mark4>
thats going to be utf8 ISH because the first 127 are the samne
<mark4>
same
f-a has quit [Quit: leaving]
<mark4>
but what if i need to be able to create a "┏━━━━━━━┓" string?
<mark4>
har blah[] = UTF8 data here, NOT ascii data ?
actuallybatman has joined #forth
<inode>
either wait for __STDC_UTF_8___ / char8_t comming in C2X, or use an unsigned char explicitly specify the characters you want by the utf-8 ordinal value rather than by symbolic appearance of the character?
<mark4>
my life would be much simpler if abominations like c++ simply did not exist lol
<inode>
actually, it seems there's a u8 prefix for strings too
<mark4>
my entire text user interface with windows and everything! in a console... is less than 30k in size!
<mark4>
tho not actually complete
<mark4>
yet
<mark4>
i dont want to add a 3248756293465293746589283745 gig cpp library to it
<inode>
char pi[] = u8"π";
<mark4>
aha
<mark4>
except. how do you TYPE that PI character
<inode>
that depends on the terminal/os you're using
<mark4>
also. i do not like that because what if i have u8"┏┓┗┛━┃┣┫┳┻╋"
<mark4>
and i want to print the nth char from that string
<mark4>
[3] is going to be 3 BYTS in not 3 utf8 chars in
<mark4>
wrong
gravicappa has quit [Ping timeout: 264 seconds]
<mark4>
also. that array, is it an array of codepoints or of the chars themselves?
<inode>
constituent chars (literal bytes)
<mark4>
do not understand what you mean by constituent chars
<mark4>
the codepoints for those chars are 250f, 2513, 2517.. . etc
<mark4>
all 16 bit codepoints
<mark4>
how many bytes per "char" in that string?
xek has quit [Quit: Leaving]
<inode>
a char is still going to be however mean bits long as CHAR_BIT is defined as, so most likely 8
<mark4>
nope. no good to me
<inode>
assuming 250f is the first utf-8 ordinal you've thrown into that string, you're likely to get 0x25 back from str[0] and 0x0f back from str[1]
f-a has joined #forth
<mark4>
i need to be able to specify a string of printable chars and have those chars stored in the string as CODEPOINTS not chars
<mark4>
right. and thats not correct for my use case
<inode>
then you're left with defining your own specialised array type and/or associated accessors
<mark4>
so im NOT storing those codepoints in strings but in uint16_t arrays which is still WRONG
<mark4>
uint16_t string_thing = u8"┏┓┗┛━┃┣┫┳┻╋" <-- this would be more correct but im betting not allowed lol
<mark4>
but again. this assumes that the "string" is stored as a sequence of codepoints
<mark4>
when you printf a codepoint does printf know its a codepoint? or do you need utf8_printf ?
actuallybatman has quit [Ping timeout: 276 seconds]
<mark4>
i need to be able to specify strings as sequences of printable chars but STORE them as arrays of codepoints
<mark4>
and i need the display functions to handle conversion from codepoint to what ever byte sequence they devolve into
<mark4>
its a clusterfuck lol
<patrickg>
when you printf a char*, the sequence of bytes stored there is emitted until the first NUL. If that happens to be utf-8 and your terminal uses utf-8 encoding, great. otherwise, less great
<patrickg>
if you care about codepoints (UCS-2 or UCS-4, depending on implementation), there's also wchar_t with L"your widechar string" which has printf's "%ls" operator for printing those
<f-a>
what if you forget the \0
<inode>
you get all subsequent bytes printed as an added bonus until it's reached :)
<mark4>
again. does that store the CODEPOINTS in the string? or the chars the codepoints expand into?
<mark4>
lol
elioat has quit [Quit: elioat]
Zarutian_HTC has joined #forth
<inode>
well take a look at sizeof(wchar_t) on your system, it might be 4 or more - which would be enough to hold a utf32 ordinal
elioat has joined #forth
<inode>
but why not just treat those glyphs as strings unto themselves and store them in an as array as such?
Zarutian_HTC has quit [Remote host closed the connection]
<kiedtl>
quick question: As a beginning forthwrite, would y'all recommend me to build a FORTH on (a) 8086 (b) 80386/x86_64 (c) z80 (d) a fantasy architecture?
Zarutian_HTC has joined #forth
<mark4>
kiedtl: do you code asm?
<mark4>
i would say do it on 32 bit x86 or on an arm linux like the PI
<mark4>
im not really a fan of 64 bit x86, i think its surplus to 99.99999999% of requirements :)
<kiedtl>
mark4: I'm not super experienced in asm, but I like to think I'm OK =>
<kiedtl>
I might look into ARM, thanks. But I don't have an available PI for testing.
<kiedtl>
Would you mind giving a rationale for your recommendations?
<mark4>
64 bit x86 is lind of a marketing gimik really. 64 bit os's are not faster than 32 bit, the code is significantly larger and forth is meant to be small :)
<mark4>
i did a 32 bit x86 and 32 bit thumb2 forth then i ported the 32 bit x86 to x64 (work in progress)
<mark4>
but tbh theres literally no advantage to having a 64 bit forth, the 32 bit forth can already do 64 bit math and until consumer machines have Tbytes of ram i dont see a need for 64 bit really
<mark4>
ya, my cpu is 64 bits but the 32 bit forth works just find :P
<kiedtl>
well, it helps to be able to address >4gb of mem without long pointer gimmicks
<remexre>
yeah, my nice amd64 box does have >256G, sooooo
<remexre>
I do indeed want long pointers
<remexre>
you can emulate all of these fast enough with QEMU though
<remexre>
incl in userspace
<MrMobius>
mark4, just curious, how did you do the x86 forth?
<MrMobius>
i always wondered if you use an x86 simulator on your x86 machine
<mark4>
which one?
<mark4>
the 32 bit or 64 bit
<mark4>
both were written in nasm assembly and debugged with GDB or ALD
<mark4>
ALD would have been cool if it had stayed maintained
<mark4>
gdb is a horrendous abomination, spawn of satan
<MrMobius>
and you can single step and catch mistakes with those two?
dave0 has joined #forth
<mark4>
with gdb its horrendously painful lol
<mark4>
i now do my asm debugging with IDA Pro
<MrMobius>
do you have to put anything into your asm to get it to work with gdb or it just works with any binary?
<mark4>
just pass it the binary. the problem is that while the assembled forth kernel can have debug info on it the extended forth does not
<mark4>
also. gdb is a bit BITCHY when you try to execute code it does not know exists
<mark4>
and straight up FLAT REFUSES to show the stack because it cant see a stack frame
<mark4>
because theres no such fucking thing as a stack frame
<mark4>
grrrr
<MrMobius>
heh so assumes a lot about what youre doing