<tp>
other places to advertise are reddit and comp.lang.forth on usenet
<tp>
I'll also add you in my list of 'other forths'
<tp>
“They used two coding languages – Python and Arduino Scratch"
<tp>
wow, maybe we should try them ?
<tp>
MrMobius, I have an answer to your question "foo bar blah"
<tp>
I'm sure that Python and Arduino Scratch are the new super dooper Forth replacements!
<veltas>
If you only knew how bad it really is
<tp>
heheh, I try everything
<tabemann>
back
<tp>
I have python, lua, elisp tests on my doc page
<tabemann>
the key sign is that they're using Raspberry Pi
<tp>
of course
<tabemann>
you know something isn't a real MCU project if it's using a Raspberry Pi
<tabemann>
it's like Arduino for people who can't even use an actual MCU
<tp>
that walking stick for the blind includes a trolley for the battery that it needs
<tabemann>
lol
<tp>
Im very familiar with the rpi as I have about 4 of them
<tabemann>
I own one Raspberry Pi which I haven't even opened the packaging for
<veltas>
I shudder to think about the internet of things walking stick
<tp>
the one I use now and again had a LED and a push button. when I want to turn it off, I press the button and the sustem is shut down properly, the LED turns off just before the shutdown so I know it's safe to pull the power
<tp>
I use C to turn the LED on and off
<tp>
and scan the push button
<tabemann>
veltas: yeah, like why on earth would a walking stick need to be an IoT device???
<tabemann>
I personally think that IoT is a disaster
<tabemann>
so many machines waiting to be compromised, which'll never, ever receive security updates
<tp>
they make a great Linux host for thinks like a ethernet connected terminal etc
<tabemann>
which'll ultimately become botnet node zombies
<veltas>
These IoT devices make great Linux hosts for the people that hack your toaster
<veltas>
BRB sshing into neighbour's lightbulb
<KipIngram>
:-)
<tp>
I can think of a great reasons for a walking stick to need wireless, just not wifi
<tp>
I'm into wireless such as zigbee and lora, but not wifi for embedded
<tp>
veltas, I wont, Im never tempted to do things because someone says dont
<veltas>
tp somehow I actually know that is the case with you, you contrarian
<tp>
hehe it is
<veltas>
Have a look at the title though at least you tease
<tp>
ok
* tabemann
watched that video and is horrified
<tp>
anything wifi is easily disassociated with another wifi AP anyway
<tabemann>
just how can a reasonable human being actually reset one of those bumbs
<tabemann>
and just why would one want a lightbulb that uses wifi?
<veltas>
So you can control lightbulbs remotely
<tp>
I've dissociated wifi clients from miles away many times
<veltas>
without screwing them in and out of socket
<veltas>
Luckily my house came with these weird plastic things I can use to cut the electricity
<veltas>
on walls and in convenient places
<tabemann>
veltas: wouldn't it make more sense to go and put some kind of base on the lightbulb rather than putting the firmware in the lightbulb itself?
<tp>
once the client is disassociated from it's AP, it begins the key auth process which you log
<tp>
and so on
<tp>
veltas, ahh you mean a "switch" ??? ;-)
<veltas>
Yes, if you want to use that old outdated term
<tp>
tabemann, and so you can, thats what I have
<tp>
tabemann, mine is X10
<tp>
I have a X10 controller plugged into the mains and it controls various devices by signalling over the mains wires themselves
<tabemann>
yep
<tp>
no wireless needed
<tabemann>
and much more secure too
<tp>
exctly
<veltas>
tabemann: The other thing about this is I think I know why they didn't just put a reset button on the bulb and it will upset you
<tp>
veltas, extra hardware and point of failure
<veltas>
Nope
<tp>
does the bulb get hot ?
<veltas>
Health and safety, it's a button on a bulb that goes in a lethal electrical socket
<veltas>
The bulb is probably an LED bulb that gets warm
<tp>
but toasters have buttons
<veltas>
tp you know it doesn't need to make actual sense
<tp>
my led bulbs get really hot
<tabemann>
all kinds of things attached to wall current have buttons
<veltas>
for it to be the reason they did this
<veltas>
It could be hottitude but I think it is a bizarre concern about someone suing them because their husband died resetting firmware with wet hands
<tp>
safety is always a factor, things like not being able to reach the button, burn fingers, heat damaging the button and extra cost of manufacturing would be higher up the food chain I expect
<tp>
veltas, yeah, very little makes sense to me these days
<tp>
the logic of Forth makes perfect sense to me however
<veltas>
I think health and safety went downhill some point between airbags and this 3 minute video
<tabemann>
back
<tp>
tabemann, how goes zeptoforth ?
<tabemann>
improved POSTPONE to do inlining
<tabemann>
and added accessor words for accessing word header fields
<tp>
nice touches!
<crest>
tabemann: i wanted "smart" light bulbs to control brightness and color temperature
<tabemann>
earlier I added 1+, 1-, 2+, 2-, 4+, 4-, 2*, 2/, 4*, and 4/
<tabemann>
because as dedicated words I realized that I could make them far less expensive, especially with inlining
<crest>
most of the time i control them through other microcontrollers via zigbee
<tp>
crest and hook them up to a ECG hat so when your gf is arguing with you the lights all go red ?
<tabemann>
because those all literally are one 16-bit instruction
<crest>
she would probably laught about that (afterward)
<crest>
but i have just one rgb bulb
<crest>
i did use the python bindings to turn it into visual bell
<tabemann>
so it was worth it to make dedicated words for all of those
<tp>
hahah
<tp>
tabemann, but youre just filling your dictionary with simple stuff with the last lot ?
<tabemann>
tp: the key thing is that 1 + is far, far more expensive, in both space and processing time, than 1+
<tp>
anyone who needs a 2+ should be using python instead ;-)
<tabemann>
and I'm not going to implement a peephole optimizer as that'll way complicate the compilation process, especially with regard to flash
<tp>
see 1+
<tp>
00002018: 4770 bx lr
<tp>
00002016: 3601 adds r6 #1
<tp>
Bytes: 4 ok.
<tp>
: oneplus 1 + ; ok.
<tp>
see oneplus
<tp>
20000426: 3601 adds r6 #1
<tp>
20000428: 4770 bx lr
<tp>
Bytes: 4 ok.
<crest>
tabemann: do you generate position independend code?
rdrop-exit has joined #forth
<tp>
far more expensive ? maybe on zeptoforth ;-)
<tabemann>
crest: individual words are internally position independent, as are short-distance calls between words
<crest>
because if you do you could just generate the code in ram and move the code in ;
<tabemann>
long-distance calls between words, e.g. between flash and RAM, are not position independent
<tp>
crest, yes and tabemanns code also disinfects all traces of Coronavirus from the bits
<rdrop-exit>
Good morning Forthwrights c[] :)
<tabemann>
hey rdrop-exit
<tp>
rdrop-exit, Zen Forth Guru !
<rdrop-exit>
hi tabemann
<rdrop-exit>
hi tp
<rdrop-exit>
(-_-)zzz c[]
<crest>
tp: i played with the code for your "free" word because it looked more complex than it should be and came up with this: https://pastebin.com/raw/yLh5XUMG
<crest>
how badly did i mess it up?
<tp>
hahah, you know you didnt mess it up at all, it's excellent
<tp>
I'm delighted to see you fixed up my crappy code!
<tp>
I wish more of my crappy code was fixed
<crest>
is the structure of mecrisp dictionary headers documented somewhere?
<crest>
i would like to write word list all words containing a substring
<tp>
now the big question, does your code work ?
<crest>
yes
<tp>
crest, yeah, it's in my doc page
<tp>
in the dictionary page
<crest>
under "Word Header Fields"?
<tp>
crest, yes
<crest>
because that lacks explicit sizes, offsets and alignments
<crest>
are all fields 32 bit aligned a 32 bit long?
<tp>
I had to ask the author for the answers to my questions about the headers
<tp>
he would say "its all in the source"
jsoft has joined #forth
<tp>
crest, your code appears to be for the F103 only ?
<tp>
crest, another issue is that if you load that word it wont work after a reset
<crest>
tp: correct
<crest>
just the flash-size constant has to change
<tp>
my shitty code is designed to work on any mcu and work after a reset
<tp>
hence it's parameter driven
<crest>
it wasn't
<tp>
oj, it is thesedays
<crest>
it just contained a bunch of cases in comments
<crest>
but all that changes is how the flash size is calculated
<tp>
*all* ?
<tp>
it's parameter driven, no need to hack the source
<crest>
i read it a few times and i'm pretty sure
<crest>
but there is no reason to carry that parameter along on the stack
<crest>
it's not like the flash size changes at runtime
<tp>
thats true
<tp>
but the stack doesnt care
<tp>
thats a programmer itch
<crest>
the human reader did
<tp>
in reality not hacking the source is much better, all my utilities are now parameter driven
<tp>
I came from a hardwired free calculatio
<tp>
+n
<tp>
wether the stack is full of zeroes or $1FFFF7C, it doesnt care
<tp>
GIGO :)
<tp>
this in no way detracts from your beautifuly neat source however
<MrMobius>
crcm re comment from earlier, what do the parenthesis do on ( baz ) in the example?
<crc>
MrMobius: nothing, other than provide a visual clue
<MrMobius>
thats neat
<tp>
MrMobius, I have an answer for your "foo bar baz" question. I couldnt even grok it last night
<MrMobius>
"last night?"
<MrMobius>
oh forgot, youre upside down :P
<tp>
MrMobius, but my subconsious was working on it while I was asleep
<tabemann>
back
* tabemann
is reading the I Hate Forth article
<tp>
yeah, the weight of my brain makes this part of the world hang at the bottom ;-)
<MrMobius>
crc, what do you think about repurposing , also as an optional marker?
<MrMobius>
hehe
<tp>
MrMobius, here is my answer " fill wash drain "
<MrMobius>
so because they are verbs we can assume they are all words?
<tp>
I wasnt able to answer 'foo bar blah" because it's totally abstract and I dont think that way
<tp>
they do what they say for a english speaker
<tp>
youre over complicating your analysis
<tp>
this is why I use Forth
<MrMobius>
what are we filling and how many? is that on the stack before "fill wash drain"? how many of those things are consumed by fill and how many are left behind?
<crc>
MrMobius, that could be done; a nice thing with forth is that everything is easy to change
<tabemann>
about <tp> I came from a hardwired free calculatio what you do is make your forth have a word that returns the flash size for the device it was compiled for
<tp>
MrMobius, it's the same as the labels on your washing machine
<tp>
MrMobius, to examine what happens with 'fill' one simply looks in the fill Word
<MrMobius>
tp, I dont think Im over complicating. I think that example is over simplified compared to the real world. it wont always be the case that you have 3 words with no input or output
<tp>
thats true, they are low level words
<tp>
right at the top will be "start"
<tp>
I had to begin with low level words for a C user ;-)
<rdrop-exit>
what is the question? I haven't had enough coffee to understand what you guys are on about
<tp>
rdrop-exit, I dont recall the question but I know the answer is 42
<rdrop-exit>
ah ok :)
<crc>
06:15:51 <MrMobius> Forth: foo bar baz
<crc>
06:16:09 <MrMobius> or the 10+ other things that could be going on
<crc>
06:16:02 <MrMobius> C: foo=bar(baz);
<MrMobius>
rdrop-exit, basically how to make Forth more readable. you dont know a word consumes or leaves behind on the stack the same way you do in C. just wondering what you could do to improve that, so not awrguing C is superior in all ways
<crc>
06:16:16 <MrMobius> bar=foo(baz);
<crc>
06:16:25 <MrMobius> bar(); foo(); baz();
<MrMobius>
lest I be flamed
<tp>
MrMobius, I didnt understand your abstract only question, and you dont understand my real world application answer
<crc>
(from earlier today in the logs)
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp>
MrMobius, no one here will ever flame you (except the occasional fake Forth using troll)
<MrMobius>
tp, what do you mean I dont understand? what would you have inside of fill for example that expects something on the stack and leaves something behind?
<tp>
MrMobius, simply put, whatever is needed
<tp>
MrMobius, but I answered your initial question in a proper Forth manner, is this a second question ?
<MrMobius>
I know but Im asking for an example if you think I dont understand
<tp>
MrMobius, obviously it's Words all the way down
<MrMobius>
my original question is about words that consume or add things on the stack so I dont think "fill wash drain" applies but of course I dont know which is kind of the point
<tp>
right at the bottom ae the hardware configuration words, thats where it all ends, or begins depending on your pov
<tabemann>
back
<tp>
MrMobius, no, your original question was "foo bar baz" ?
<tp>
no question expansion is acceptable ... :)
<tp>
a C coder says "foo bar baz " to which a Forth user responds " fill wash drain"
<MrMobius>
right but I think you assuming that "foo bar baz" are three words the same way "fill wash drain" are three words is getting to the core of the problem. what if foo and bar are variables and baz consumes them? what if bar consumes foo but leaves something behind which baz expects? there are a lot of things that could be happening
<crc>
you have to keep a mental picture of the stack state are as you read the code
<tp>
MrMobius, your questions are awesome btw, you bring a refreshing view, clearly put
<tp>
MrMobius, yes, there may be inputs and outputs associated with many words, Forth can take unlimited paramaters and supply unlimited outputs, we have a system that tells us all of this
<MrMobius>
the best ive figured out is to hunt down the stack picture for the word and copy it into the word calling that word. non ideal but better than nothing
<crc>
in my system, I use consistent naming conventions for variables, constants, words, etc as well as token prefixes, so my code provides a degree of semantic information
<tp>
MrMobius, none of this is a mystery to me
<MrMobius>
tp, what is the system? how do I tell what happens to the stack without looking up the stack picture for each word?
<MrMobius>
crc, ya I think that goes a long way
<tp>
MrMobius, when I started learning forth for few years it was a mystery to me however
<crc>
doesn't help with indicating values consumed/left, but that's where other tools (e.g., in the editor) can help
<rdrop-exit>
I don't see the problem
<tp>
MrMobius, thats a odd question, how do I follow a C program without looking at the source code ?
<MrMobius>
crc, like a window that shows the declaration when your curcsor is on the word?
<tp>
MrMobius, each word should have a stack picture, thats part of the Forth code
<rdrop-exit>
some Forths have VIEW
<tp>
MrMobius, and it's only been about a week since I realised that most of my stack pictures are crap (thanks rdrop-exit!)
<crc>
MrMobius: that's one way
<MrMobius>
tp, its instantly obvious what is put on the stack, what comes off, what is expected, and what is passed in C. whatever permutation you do: foo(); bar(); baz();, foo(bar(),baz());, foo(bar(baz()));, foo(bar); baz(); etc you know what's happening. no way to tell that from "foo bar baz" in forth without the stack picture in the declaration
* crc
has numerous specialized editors for his code, exploring different ideas
<tp>
MrMobius, I disagree, "wash spin drain" needs no further elaboration
<MrMobius>
rdrop-exit, so VIEW would provide the comments from the declaration too?
<rdrop-exit>
VIEW shows you the source
<tp>
MrMobius, theer is NO "foo bar baz" in any Forth program.
<MrMobius>
tp, yes for that very simple example. not so for words that take things off the stack or leave things on, which is much more common
<crc>
well, `foo bar baz` shouldn't have foo consuming values from bar and baz since those would be evaluated after foo
<tp>
if one cannot understand "spin wash drain" they must be a russian only speaker/reader
<tp>
it's the RUSSIANS!
<MrMobius>
crc, ya the ones where foo uses ' to call bar and baz are probably less common
<MrMobius>
crc, what have you done in your editors?
<crc>
MrMobius: that's not doable in my system; you'd have to pass data on the stack; I don't provide a forward parser
<tabemann>
using ' to call a word is bad practice
<tabemann>
using ' to capture a word so it can be, say, postponed is another matter
<crc>
MrMobius: I have a few that look up stack comments and descriptions from a database as code is entered/edited, and one in which my browable glossary is available in a pane
<rdrop-exit>
Mr. Mobius, you're mixing the what with the how
<MrMobius>
tabemann, true but maybe using it to capture a variable is more common
<crc>
tabemann: no ' in mine at all
<tp>
MrMobius, re the stack, it took me ages to understand that a forther MUST be able to read the stack to understand whats happening, the 'invisibility' of the stack was a problem for me for quite a while
<tabemann>
I use "token" in zeptoforth frequently to grab a name off what is being compiled, so it can have something named by it, but I practically never use ' within a word to grab a name when it is executed
<tabemann>
for instance, when I defined VARIABLE I used TOKEN
<tabemann>
TOKEN itself only grabs a string, nothing more
<rdrop-exit>
The word wash does the washing, if you want details you look at the docs or source
<MrMobius>
with no ' you still have at least 6 different things that could be happening
<tabemann>
the only case I use ' is for turning names into xts at the REPL
<tabemann>
within a word I use ['] to do the same
<tp>
rdrop-exit, exactly :)
<MrMobius>
rdrop-exit, right but wash is tp's example which im saying is oversimplified. if you looked inside wash you would probably end up finding a word that uses the stack to pass data to another word. when you find that, it's probably not obvious what it takes from the stack and leaves on until you look up the delcaration
<tp>
ask a housepersibling what 'wash' means they will know :)
<tp>
MrMobius, youre right of course, it's Words ALL THE WAY DOWN
<tp>
MrMobius, but why would you assume that underneath those three primitive words, things suddenly become obtuse and unclear ?
<crest>
how evil are words with input dependend stack effects?
<rdrop-exit>
That's the point MrMobius, the stack is implicit, that's what makes the code readable, I can change the interface between WASH and SPIN
<MrMobius>
tp, I think youre missing the point. its obvious "wash spin dry" is three words that leave nothing on the stack. can you give an example where info is passed between words?
<tp>
crest, no more evil than C functions that expect parameters
<tp>
MrMobius, why? this is a clasic case of Forths superior 'information hiding' :)
<MrMobius>
rdrop-exit, given tp's example, what is the interface between WASH and SPIN?
<crest>
words that return 1 (false) or 3 (addr len true) results depending of if they found a match
<tp>
MrMobius, you dont need to know, al you need to know is that wash washes, spin spins, and drain drains
<rdrop-exit>
that's the point, the interface can change
<crest>
its tempting, but i'm afraid future me will stumble over it
<rdrop-exit>
but you still have WASH SPIN
<MrMobius>
yes, i was pretty astounded in Starting Forth when I read the phrase "information hiding" and the author meant that it was a good thing :P
<tp>
MrMobius, it is at the higher levels, you dot need to know how the words interact at that level
<crc>
crest: just document it and refer back in the future if you run into issues
<rdrop-exit>
notthing is hidden in Forth
dave0 has quit [Quit: dave's not here]
<tp>
crest, you sure will, but Forth won't generally let you. If you omit a parameter you'll usually get a 'stack underflow' error
<MrMobius>
I suppose you could write WASH SPIN in some way then never change the interface in which case it doesnt matter what the pass and how but if I had to modify or improve WASH SPIN, how would I know what's on the stack? there's no real way other than looking up the stack picture. my point is if there was a way to provide that info like you always have in C, Forth would be much more readable
<MrMobius>
rdrop-exit, it's hidden if I have to hunt through a bunch of files to find it
<rdrop-exit>
I don't think Forth would be more readable that way, it would be more cluttered
<tp>
MrMobius, please dont feel that rdrop-exit and I are ganging up on you, I cant speak for rdrop-exit but my only motivation is to find a way to explain this to you in a way that will make sense to YOU
<MrMobius>
tp, no its fine. this is interesting
<tabemann>
MrMobius: how is this any different from any other language - if I'm programming in Java, and I have a function I'm calling, the only thing different about it is that IntelliJ will look up the signature for me
<rdrop-exit>
you only have to hunt through files if that's the way you coded your Forth
<tp>
MrMobius, consider this "wash() spin() drain()"
<tp>
MrMobius, consider this "wash(); spin()' drain();"
<tp>
oopes
<tp>
you know what I mean
<MrMobius>
rdrop-exit, as opposed to putting everything in a huge file?
<tabemann>
and I bet someone could create a Forth IDE which would look up the signature for me too
<rdrop-exit>
has opposed to haviung yout editor do whatever you need it to
<tp>
look how complex those three simple functions have become
<tabemann>
but Forth users typically aren't the sort to bother with IDEs
<rdrop-exit>
I disagree tabemann, a Forth is by definition an IDE
<tp>
tabemann, I use a IDE according to the definition
<MrMobius>
tabemann, its different because you dont need the signature in Java to know what is going onto and coming off the stack. foo(bar,baz) tells you right there whats going where. you could easily modify that, which you cant do without looking through files and trying to figure out what those 3 things are
<tp>
hahah, SNAP
<KipIngram>
rdrop-exit, I think he means graphical IDEs.
<tp>
KipIngram, mine is a GUI IDE
<tabemann>
I mean like Eclipse, IntelliJ, Visual Studio, Visual Studio Code, and like
<rdrop-exit>
doesn't matter if it's graphical or not
<rdrop-exit>
you can setup your Forth so that pressing a key combination shows you whatever you want
<rdrop-exit>
Forth has always been a customizable IDE
<rdrop-exit>
It's not just a "language", it's an environment
<rdrop-exit>
You have however many tools you want at your disposal
<tp>
exactly
<rdrop-exit>
as many tools as you want
<KipIngram>
I agree with you - I do consider Forth an IDE.
<KipIngram>
It's kind of "one stop shopping."
<MrMobius>
ya interactivity is nice
<tabemann>
I have a question - when is the last time you used Eclipse or IntelliJ
<tp>
of course unlike C users, Forth users BUILD their own IDE's and no two are alike in my experience
<KipIngram>
The mainstream languages and OS's have gotten things so that "writing code" is an entirely different "arena" from "navigating the OS."
<rdrop-exit>
that's one of the reasons you can keep your code less cluttered
<tp>
me- never, perish the thought
<KipIngram>
In Forth they're seamlessly connected.
<KipIngram>
It's CLEARLY a superior paradigm.
<rdrop-exit>
exactly
<tp>
I've seen Eclipse, slow, horrible
<rdrop-exit>
My forths are not command line driven, I process every keystroke
<tabemann>
because when I think of the term "IDE", I think of an environment where the editor parses your source code for you, displays errors before you even compile, allows you to see signatures by just mouseovering function names, allows you to jump to function definitions by control-clicking on their names, and so on
<tp>
lol, I installed "Atollic Studio" on a Intel NUC for fun. it downloaded GB of stuff, and took about a hour
<MrMobius>
ok here's an example: does the amount of time you SPIN depend on the amount of time you WASH in this code: WASH SPIN DRY? consider the same question which these two alternatives "wash(); spin(); dry();" vs "time=wash(); spin(time); dry();"
<tabemann>
an environment that tries to do everything for you, and is big and bloated as a result
<rdrop-exit>
Tabemann, your thinking of particular implementations of the IDE concept, the concept has been around forever
<tp>
MrMobius, excellent questions :) and easily answered. To find the answer you look in each lower level Word, everything will be there, and if not, you follow the Words until you find it
<rdrop-exit>
* you're
<rdrop-exit>
MrMobius customize your tools, rather than cluttering the source
<MrMobius>
tp, that's correct but that is a real pain whereas it only takes as long as I need to read the line of code in C
<tp>
MrMobius, when you get to the bottom of my code, youl find all the low level stuff and thats it. Everything you need to know will be clearly explained tho you may (understandably) wonder WTF is going on if you cant follow the stack operations
<tp>
MrMobius, that's not correct, I showed you why last night
<tabemann>
any good Forth code will have stack signature comments
<rdrop-exit>
MrMobius, but you pay for that information being in the c code at the surface level by having much more cluttered C source
<tp>
NO one can follow all C lines of code, thats utterly preposterous
<MrMobius>
tp, thats right. this is the core of the question. why should I have to look up words that call words that call words and hunt this down which takes time when you could instantly answer that question for yourself in C. im trying to think of a way to make that info also instantly available in Forth
<tp>
take my example of last night "void TIM_TIxExternalClockConfig(TIM_TypeDef* TIMx, uint16_t TIM_TIxExternalCLKSource, uint16_t TIM_ICPolarity, uint16_t ICFilter);
<MrMobius>
tabemann, yes but only for the declaration. if you have 5 words on a line, you dont recopy the stack signature comment for all five onto the line and do that for every word
<tp>
you dont understand that, I dont understand that
<rdrop-exit>
ah! my eyes =8-O
<tp>
which timer is it ?
<MrMobius>
rdrop-exit, ya I could see having much more ambiguous code that is difficult to read if it reduces the clutter. I guess its the trade off
<MrMobius>
tp, I understand what is happening to that stack
<KipIngram>
Eclipse is awful.
<tp>
it's totally FOOBAR, and there is the answer to your "foo bar baz" question ;0-)
<rdrop-exit>
but it's not more difficult to read, you're definition of readability is off
<KipIngram>
I have a more general definition of IDE.
<MrMobius>
tp, thanks for trying but thats not an answer :)
<KipIngram>
And IDE is any environment you can both develop and execute in.
<MrMobius>
rdrop-exit, so maybe more readable but less information available at a glance?
<rdrop-exit>
yes
<tp>
MrMobius, you dont have a clue what is happening, you only think you do. Please prove wrong. answer this ... whicg timer is it ?
<rdrop-exit>
KipIngram, my definition of Forth is Total Interactive Control :)
<tp>
I cant see which timer it is, can ANYONE HERE ?
<MrMobius>
tp, thats beside the point. im talking about what goes on an off the stack. that is easy to see every time someone calls that C function
<tp>
MrMobius, it's *exactly* the point to me
<MrMobius>
tp, maybe that is a different question which is important to you which is fine but that is separate question to the one I asked
<tp>
the timers are different, they have different configs
<MrMobius>
although no objections to changing the subject if thats what youre going for :)
<tp>
I asked this question :)
<tp>
the subject was "foo bar baz"
<rdrop-exit>
In a very high level word what goes on on the stack is an implementation detail
<tp>
this is part of my answer
<tp>
rdrop-exit, is right
<tp>
the stack details are easily understood by a Forth programmer
<MrMobius>
tp, I dont know which timer it is and you wouldnt know either if the forth words were named the same as the C in your example. if you have a more clear way of naming things in Forth, thats not a Forth advantage. you could also rename those things in C
<tabemann>
when programming in Forth I very rarely need to go back and look up the signatures
<rdrop-exit>
just as how your button is wired up behind the scenes in a radio is an implementation detail
<tp>
in the same way (apparently) that MrMobius understand the C function above that made rdrop-exit eyes bleed
<MrMobius>
tp, tell me this, how many things go on the stack and how many come off in that C function? and yes it is ugly 0_0
<tabemann>
and almost always I follow very well-defined conventions as to how arguments on the stack are organized
<tp>
MrMobius, yes, no one knows, no one offered to explain that line of C from the STM factory std peripheral library
<MrMobius>
tp, void means nothing goes onto the stack and the four arguments mean four things go onto the stack
<tp>
MrMobius, that C line isnt ugly, it contains NO USEFUL INFORMATION
<tabemann>
MrMobius: how simple is C code where there are pointer arguments that are both inputs and outputs
<MrMobius>
at least it behaves that way even if the values are in reality held in registers
<tabemann>
some pointer arguments are inputs, some are outputs, some are both
<tabemann>
how easy is that?
<KipIngram>
rdrop-exit, I can get behind that definition as well.
<tp>
MrMobius, I understand that C code, I know what it's doing. Thats why I know it's useless
<KipIngram>
It's just so completely different from anything else out there, you'd think it would get more attention than it does.
<MrMobius>
tabemann, I havent seen that often but that would be annoying. its separate issue though from what gets passed and returned, ie not arguing C is good just that its easier to tell whats coming and going
<KipIngram>
Never mind "better or worse" - just because it's *different*.
<KipIngram>
Of course, I think it's better.
<tp>
MrMobius, do you think I could write Forth code if I didnt understand what parameters are expected and passed ?
<MrMobius>
rdrop-exit, its interesting that you prefer the readability. do you find yourself modifying words very often in practice and does that ever slow you down?
<tp>
MrMobius, or anyone else here ?
<KipIngram>
Readability is a big deal.
<tp>
readability is everything
<KipIngram>
Well-written Forth reads almost like English documentation of the application process.
<KipIngram>
And believe me - it takes some work to get that done WELL.
<rdrop-exit>
I modify words whenever a better way to do something occurs to me
<tp>
ie "wash spin fill"
<KipIngram>
It's as easy to write trash Forth as it is to write trash anything else.
<tp>
yes. Forth is a code multiplier, bad Forth is disgusting, good Forth is beautiful
<KipIngram>
In Thinking Forth, they talk about the application development process as the process of developing a lexicon related to your app.
<KipIngram>
Makes TOTAL sense to me.
<MrMobius>
I dont think trash Forth is the issue. even the best Forth doesnt tell you whats going on and off the stack without comments
<KipIngram>
Well, that's true.
<tp>
agreed
<KipIngram>
Understanding the general flow of the problem solving is a different kind of understanding from full stack knowledge.
<KipIngram>
Those are two different "hats."
<tp>
a lack of comments for ANY programming language makes it unreadable
<KipIngram>
Well, the very BEST Forth has the source code read almost like the comments.
<KipIngram>
To some degree, the source documents itself.
<KipIngram>
But like I said above, that is HARD.
<KipIngram>
And if you don't achieve it, you should comment.
<MrMobius>
rdrop-exit, I mean maybe this annoying situation I get in where im looking up words that call words that call words and have to get to the bottom to figure out the stack picture before I can change anything doesnt happen that much in what you do or its not that big of a deal
<tp>
getting stuck in the detail of a stack, when examining a tested word is kinda useless if youre just following the program flow
<KipIngram>
The stack picture is best understood from the bottom up.
<KipIngram>
The top down analysis should be about the abstract problem solving.
<MrMobius>
tp, ya if youre just skimming to see whats going on but if you need to jump in and interrupt that flow to improve something you need those details
<crest>
does mecrisp stellaris include tail call optimization?
<tp>
KipIngram, " the source documents itself" is only true for the best forth, never for C
<KipIngram>
Top down, you don't care HOW it's being done - you care about WHAT'S being done.
<KipIngram>
I agree, crest.
<KipIngram>
It's impossible in C, and damn rare in Forth.
<KipIngram>
It's kind of an "idealization."
<tp>
MrMobius, and all those details are there, even if hard to see for someone expert in C and not so much in Forth
<tp>
KipIngram, absolutely agree
<MrMobius>
hehe, "hard to see" is a good way to put it :P
<tp>
MrMobius, I sure spent YEARS understanding that the secret to understanding Forth code is the stack
iyzsong has joined #forth
<tp>
I wrote various 'helper' stuff to try and get there
<tp>
I came from C (simple embedded C) and it was hard for me
<tp>
I knew assembler, machine code, pascal etc
<tp>
what happens on the stack can be a utter mystery, so time must be spent deconstructing it
<KipIngram>
IF you achieve a truly graceful and optimum Forth solution, then writing comments should feel like repeating yourself.
<tp>
at least at my level
<KipIngram>
I really don't want to understate the difficulty of doing that.
<tp>
KipIngram, true, but it's IMPOSSIBLE in embedded
<KipIngram>
Well, certainly documentation of the layout of registers and so on is required.
<KipIngram>
I think you're right.
<tp>
KipIngram, consider this ": RCC_AHBENR_TSCEN ( -- x addr ) 24 bit RCC_AHBENR ; \ RCC_AHBENR_TSCEN, Touch sensing controller clock enable"
<KipIngram>
Well, I might quibble over word names.
<KipIngram>
But yes - I think we're on the same page here.
<tp>
thats automatically generated from the ARM CMSIS-SVD after some XSLT processing
<KipIngram>
The hardware has to be documented too, and there's no source for it.
<tp>
KipIngram, if you change the word name, then you cant search the factory technical PDF
<KipIngram>
You could imagine extending Forth so that the syntax of the language defined those reg layouts, but most Forth's don't go there and I think it would come at an efficiency cost.
<tp>
that's my 1:1 correspondence of code to factort tech manual
<tp>
it's the lowest level of all my code
<tp>
and of course it soon gets upped to smarter words, but one can trace everything back to the peripleral_register_bitfield in the tech manual
<rdrop-exit>
MrMobius, read top down for a general understanding of the application, read bottom up for a detailed understanding of the implementation
<tp>
and then copy and paste the word name into a tech manual to find the exact technical descrtion of that bitfield
<tp>
rdrop-exit, well said, better than I could put it
<tp>
rdrop-exit, tho mine is the reverse in the literal sense, in that the top of a file is read first and must contain the lowest level and ugliest words. The bottom of the file is read last and contains all the high level words, like "fill wash spin drain"
<rdrop-exit>
yes, code is written bottom up, although you can sometimes have stubs for some of the high level words you intend to build up to
<tp>
rdrop-exit, describing forth code methods styles is hard, but it's utterly difffernt to C
<tp>
as all forthers know
<tp>
I often write the high level stubs first
<tp>
and then write and TEST the low level stuff and test it
<KipIngram>
I think it's fun when we start comparing notes on how we've achieved "feature X."
<KipIngram>
The really beautiful thing about Forth is that it lets you do stuff like that, in myriad ways.
<KipIngram>
Just so damn flexible.
<rdrop-exit>
me too, I enjoy such comparisons, good food for thought
<KipIngram>
Absolutely.
<rdrop-exit>
need more c[] coffee, brb
<KipIngram>
tp, re: the factory PDF, only the definition that is extant when the system comes up and is waiting for you input is important.
* tabemann
is trying to figure out how to even implement DEFER/DEFER!/IS in zeptoforth
<KipIngram>
If someone used that name for something else during system implementation, the so be it.
<tabemann>
because it has to be able to do so in flash
<KipIngram>
But in my system redefining a system word would break the system - all the internal uses of that word would then target the new defiintion.
<KipIngram>
Unless I'm in a different vocabulary, which I am.
<KipIngram>
On start-up, the user gets a clean vocab.
<KipIngram>
And is therefore unable to change those internal usages of words.
<KipIngram>
But they still can redefine the word for their own purposes if the want to.
<KipIngram>
Definitions only get revised if the existing definition is in CURRENT, where the new definition is going.
<rdrop-exit>
c[] back
<KipIngram>
Going back to the earlier discussion of comments vs. self-documenting code, I do think that stack effect doc is always important. For exactly the reason we discussed earlier - the code might express the problem solving algorithm well, but that's just different from the nitty-gritty definition of each and every word.
<KipIngram>
So I don't really think "no comments" is feasible - I think a case could be made that a "great" Forth program could only have stack effect comments.
<rdrop-exit>
I agree, every definition should have a stack comment
<KipIngram>
And that comment can be used for interesting purposes. I've got plans for a compile time local variable system that would use those comments.
<KipIngram>
You may remember that I have words to fetch and store the top several entries of the stack frame.
<KipIngram>
1@, 2!, etc.
<KipIngram>
A compile time only locals system could let you refer to those data by name; the compiler would substitute the appropriate frame access word.
<KipIngram>
Generally speaking, I'm fairly tolerant of compile time effort, but pretty much absolutely intolerant of run-time overhead.
<rdrop-exit>
I don't do locals
<KipIngram>
I'm only open to them if the cost is strictly compile time only.
<KipIngram>
I haven't actually implemented that yet - just thought about it.
<tp>
KipIngram> tp, re: the factory PDF, only the definition that is extant when the system comes up and is waiting for you input is important. ????
<KipIngram>
And yes, I do understand that it's a mechanism that could be abused.
<KipIngram>
If you get too carried away with it, it can be a route to sloppy code.
<tp>
KipIngram, I dont understand your comment
<rdrop-exit>
The stack on my PC host is not in addressable RAM
<KipIngram>
tp: My system has headers separate from bodies.
<KipIngram>
And, my system is indirect threaded.
<KipIngram>
If I redefine a word that already exists in the CURRENT vocabulary, I overwrite the header PFA pointer with the new value.
<KipIngram>
So not only have I redefined the word for future use - I've redefined the code that will execute when any prior use of the word runs as well.
<tp>
KipIngram, no Forth will have all those bitfields in it's definitions
<KipIngram>
That extra level of indirection makes that possible.
<KipIngram>
Uh oh - I'm not sure we're on the same page.
<KipIngram>
Calibrate me a bit more on what you're wondering about?
<tp>
KipIngram, possibly, my pages are small, like a childs blackboard
<tp>
KipIngram, you mentioned 'factory pdf's'
<KipIngram>
Oh. Someone else mentioned that before me.
<KipIngram>
My interpretation of it was that the OP was looking for a definition of all words used within the factory implementation.
<KipIngram>
And if you can re-define words, that gets harder and more involved.
<rdrop-exit>
My PC host Forth doesn't separate it's own headers, but I usually have separated headers on the host Forth for target words
<KipIngram>
That makes sense, rdrop-exit.
<KipIngram>
Feels right.
<KipIngram>
But I only have the one level - I'm not tethered.
<KipIngram>
When I've learned stuff about your tethered implementation in the past, I've generally felt that you made super good decisions.
<rdrop-exit>
thanks
<tp>
KipIngram, in my world the factory PDF's define all peripheral, register and bitfield names, and if any are changed, the factort technical pdf becomes useless
<tp>
KipIngram, this happens in many forths where authors just ake up their own names, making their code impossible to follow
<tp>
and it happen in a lot of C code
<tp>
it's a frigging disaster of epic proportions
<tp>
those items cannot have their names changed in any way
<rdrop-exit>
I don't mind as long the correspondence is documented in a comment
<KipIngram>
tp that makes sense. But my system does't REQUIRE that you redefine any words. And since you get a fresh vocab from the first prompt, you can't redefine a system word unless you jump through special hoops to do so.
<KipIngram>
The factory PDF can be kept righteous.
<tp>
KipIngram, I see, you have vcabs or the like ?
<tp>
rdrop-exit, fair enough, will the 17,000+ comments clog up your shadow pages do you think ?
<rdrop-exit>
Only the day I'm actually using all 17000 for something
<tp>
:)
<tabemann>
back
<rdrop-exit>
I only add words to my Forths as I need them
<tabemann>
redefining words that are in flash isn't even feasible without a mass erase in zeptoforth
<tabemann>
because once they're written, they're written
<tp>
WHAT!! I want my money back!
<tabemann>
and once words refer to them, they're referred to
<tabemann>
like I just implemented DEFER and DEFER!
<tabemann>
once a word is set in flash with DEFER!, it isn't going to change
<tp>
tabemann, Mecrisp-Stellaris is exactly the same, but you can redefine them, however previous words using them wont change
<tabemann>
exactly
<tabemann>
you can redefine them, but that doesn't change what already refers to them
<tabemann>
I actually rely on that in initialization
<tp>
tabemann, which is usless to me in most cases, so when I change any code it all gets reuploaded to ram
<tp>
tabemann, yeah, Im going to use that 'feature' in my new bluepill developer edition
<tabemann>
what I mean is that each bunch of code defines an init word
<tabemann>
and each of those calls the previous init word
<tabemann>
so each init word calls the next all the way down
<tabemann>
this wouldn't be feasible of redefining init replaced the previous implementation
<tabemann>
*if
<tp>
sure
<tp>
my binary releases include a init word to get everything going but I think I can inform users that they can make a new init word that must include a init before it to initialise my init word in the release
<rdrop-exit>
DEFER isn't worth the trouble on an SRT/NC Forth target
<tp>
if they want to make some code additions permanent
<rdrop-exit>
variable 'foo
<rdrop-exit>
: foo ( -- ) 'foo perform ;
<tp>
which they can then remove using a preset corrnerstone
<KipIngram>
tp: I hear what you're saying, but I think I've addressed the issue.
<KipIngram>
My system (currently, though it would be easy to change) WOULD allow you to redefine system words. But that's not the default behavior - you have to go to some degree of trouble to do so.
<tp>
KipIngram, Im still working on everything and value all comments inc those that disagree, it's all good, how would I improve otherwise ?
<KipIngram>
You'd have to make the system vocabulary CURRENT.
<KipIngram>
Otherwise it will never happen.
<tabemann>
back
<KipIngram>
So, you'd have to WANT it, and in that case, more power to you - try to know what you're doing.
<tp>
KipIngram, whay would you want to change system words in regard to mcu peripherals/registers/bitfields ?
<tp>
those are all additions to my definitions in every project
<KipIngram>
You usually wouldn't. So don't.
<tp>
exactly
<KipIngram>
You're not going to do it by accident.
<tp>
my system words never change, I wouldnt know how as i didnt design Mecrisp-Stellaris it's well beyond my current ability
<tp>
Im just a Forth user
<KipIngram>
On the other hand, if you DO want to redefine (KEY) and/or (EMIT), you CAN.
<KipIngram>
KNOW WHAT YOU ARE DOING.
<tp>
I dont!
<KipIngram>
I don't believe in system protecting me from myself.
<rdrop-exit>
everything is changeable in Forth
<KipIngram>
^
<tp>
the standard release is 99% fine for me, I do modify the USART to add RTS handshaking however
<tp>
and I have the usual 3 tons of addons
<rdrop-exit>
metric tons?
<tp>
yes
<tp>
i have the usual 1ee99 development files but rather than a system of #includes and nesting etc, I just cat them all into one file, strip all comments and upload it asap to the target
<tp>
simple and fast
<tp>
all proven files get uploaded at the start of the project into flash where they generally stay until the end of the project
<tp>
all development files go into ram and get reuploaded every change
<tp>
it's as fast a resident target Forth as I can make
<tp>
my tethered Forth uses exactly the same methods
<KipIngram>
tp: I'm pretty hard ore about wanting the system to give me flexibility and not try to control what I'm doing. You're tastes on that front may vary, and another great thing about Forth is that it lets us each have what we want.
<rdrop-exit>
what is the airspeed velocity of an unladen forth?
<tp>
heheh
<tp>
460800 bps of course!
<rdrop-exit>
:)
<tp>
KipIngram, agree 100%
<KipIngram>
s/You're/Your/
<tp>
KipIngram, I'm only describing what I do, I know that forthers are totally independent thinkers and do what they want, thats how Forth is
<rdrop-exit>
yes, we reserve the right to be wrong each in our own unique way :)
<tp>
if they did all the same stuff theyd be C users ;-)
<tp>
KipIngram, I'm here to help new Forth *embedded* users and learn from people like rdrop-exit and yourself
<tp>
I have nothing to offer to PC Forth users
<tp>
KipIngram, Im a electronics technician, not a Forth system implimenter
<KipIngram>
Cool - it's all good. You're bringing up very worthwhile issues.
<KipIngram>
Hope we're able to help you along.
<KipIngram>
I'm 57 currently, and discovered Forth spring semester of my freshman year, so I've been at it for almost 40 years.
<KipIngram>
Forth itself has changed a good bit over that time.
<KipIngram>
So I tend to have affinity for the more old-fashioned concepts.
<KipIngram>
tp - one of the modern concepts that threw me for a while (not that I didn't understand it - I just wasn't *putting the pieces together in my head*) was the core-local cahces in modern CPUs. I worked out a whole system for mutli-threading, but it turned out to be bogus because it involved core N doing some of the work, then passing data structures core N+1 to get more work done, and so on.
<KipIngram>
But once N passes the data to N+1, N+1 has to fetch it into its own cache.
<KipIngram>
Guy at work said they'd tried our product's application that way, and that issue kills the performance.
<KipIngram>
When I first formed my Forth expertise, we had single-core CPUs with no cache.
<KipIngram>
And the rules in that situation are just different.
<KipIngram>
"Understanding" the new rules is fairly easy - getting them driven down into your gray matter so that following them becomes instinctive is not nearly so easy.
<KipIngram>
I think the only real way to do that is to work on problems in the area.
<KipIngram>
You make mistakes, you understand why they were mistakes, you fix them. And you do that over and over and new instincts form.
<KipIngram>
Unfortunately for me (well, or fortunately, depending on how you look at it) I moved into management right around the time multi-core was becoming common. I still got my hands dirty, but not in the same way a guy that did it all day every day would.
<KipIngram>
So I was kind of deprived of that "training."
webchat9 has joined #forth
<tp>
KipIngram, I'm at the really low end of embedded, single core only. Even a old z80 would probably do most of the things I need, but a STM32 also has all the peripherals built in
<tp>
KipIngram, I think Im more of a Forth traditionalist, I have no desire to change forth, but I need speed in my IDE so I've designed for that
<KipIngram>
The great thing about life back in those days was that the absence of cache memories made the execution time of instructions fixed cycle count.
<KipIngram>
So you could analyze EXACTLY how much time your code was going to take to run, which is kind of a godsend for "tight" real-time programming.
<KipIngram>
Technically this is still possible, but there are so mny variables involved now that it's not very practically possible.
<tp>
well the great thing about these days is the mcu's are so fast, cycle count doesnt matter much
<KipIngram>
Oh, it could.
<KipIngram>
Depends on your application.
<tp>
sure, but not in my world
<tp>
I'm mostly human interface and electro mechanical
<KipIngram>
That's fine - it wasn't always that way in my world either.
<tp>
sure
<KipIngram>
But it was comforting to know that it was slam dunk easy to know your execution speed.
<tp>
generally tho if you need 200Mhz response, a fpga gets involved I believe ?
<rdrop-exit>
Still important when predictability and consistency is required rather than average speed.
<KipIngram>
Well, the same concepts applied to those. Yes - you shift to FPGA when you need more speed. But they have a speed limit too, and knowing exactly what was within reach was useful.
<tp>
frankly I never cared much, industrial, instrumentation, electromechanical are all usually dead slow
<KipIngram>
All you need is a "the faster the better" application, and your boss will be asking you how fast it can go.
<tp>
you guys are definitely programmers :)
<tp>
it's a crazy age, numbers sell, speed sells, bosses are MBA clueless
<rdrop-exit>
predictability and consistency is very much a safety critical concern
<KipIngram>
I'm not. I'm a hardware guy, by training. I've done a fair bit of "solo" programming in my time, but the early part of my career was hardware design and the latter part was managing engineering teams.
<tp>
KipIngram, wow, Ive always been the guy who builds the gear for the engineer, I'm a tech
<KipIngram>
I wouldn't try to stack myself up against a quality computer science dude on the software side.
<tp>
a java CS guy ?
<tp>
a C CS guy ?
<tp>
rdrop-exit, safety critical systems are regulated by law, I dont do any of that
<tp>
no flight controllers here, no fuel rod positioners
<rdrop-exit>
sure, I'm just saying that predictable cycle times are not just a "programmer" thing
<rdrop-exit>
time-triggered systems are all about the predictability of the exact point in time code will run, and minimizing interrupts to achieve that predictability
<rdrop-exit>
i.e. the focus in on predictability and consistency rather than bursts of speed at their expense
<rdrop-exit>
this is also related to what KipIngram was saying about the effects of cache on predictability
<tp>
sure, in 1987 I was designing embedded gear that relied on 10 nanosecond reliability for correct operation
<KipIngram>
The best CS guys I've known in my time have been damn good. It's a different profession - has its own place.
<tp>
techs are not strangers to precise timing
<KipIngram>
There's a lot more to it than just slinging code.
<rdrop-exit>
exactly tp
<KipIngram>
tp - Exactly.
<KipIngram>
You could do that then, in a fairly straightforward way.
<tp>
KipIngram, agree, times have changed
<KipIngram>
The progress in CPU performance have fairly well blown that out of the water. Not "theoretically," but practically.
<tp>
KipIngram, but my stm32f051 cache is turned off by default, still not a issue for me
<KipIngram>
You'd have to track damn near everything going on in your pgram in order to have the info you needed to decide if a variable was or wasn't in the cache, in a general way.
<KipIngram>
s/pgram/program/
<KipIngram>
tp That's great - one less complexity for you.
<tp>
and anyway, I dont need 10ns repeatability now, the peripherals I use are allready sorted inside the chip
<tp>
KipIngram, yes, I only select the things that meet my needs
<KipIngram>
:-) Smart man.
<tp>
Ive made my world suit me for quite a while
<rdrop-exit>
it's important to be selective :)
<tp>
I decided I didnt want windows in august 1997, I havent had it on a PC since then
<tp>
it was Linux for about the next 18 years then FreeBSD
<tp>
my only regret is that I took so long to get around to Forth (2014)
<tp>
but better late than never, Forth has taken my embedded fun level back to what it was in the 70's
<rdrop-exit>
cool
<tp>
I reached the point with Perl after about 12 years that I knew I could use it to do anything, I definitely have that feeling with Forth now for embedded
<tp>
there is still heaps I dont know about Forth but I know enough now to be useful
<tp>
at least to myself
<tp>
my 'blue pill diagnistics' Forth binary has now been downloaded 228 times as of today
<rdrop-exit>
lunch is on the table, catch you later, stay healthy
<tp>
not one single fault report yet
rdrop-exit has quit [Quit: Lost terminal]
<tp>
cya
gravicappa has joined #forth
dddddd has quit [Remote host closed the connection]
reepca has joined #forth
webchat9 has quit [Ping timeout: 260 seconds]
webchat9 has joined #forth
reepca has quit [Ping timeout: 258 seconds]
reepca has joined #forth
reepca has quit [Remote host closed the connection]
reepca has joined #forth
<tp>
MrMobius, after your C chat I obtained the STMicro StdPeriph library for the STM32F0 that I use and have found a good additional resource of config information, so thank you !
dne has left #forth ["WeeChat 2.8"]
dddddd has joined #forth
reepca has quit [Remote host closed the connection]
reepca has joined #forth
webchat9 has quit [Ping timeout: 240 seconds]
<veltas>
: NEGATE ( n -- -n ) 0 SWAP - ;
reepca has quit [Ping timeout: 256 seconds]
<tp>
see negate
<tp>
0000207E: 4770 bx lr
<tp>
0000207C: 4276 negs r6 r6
<tp>
:)
<veltas>
I wrote an implementation in assembly as well
<veltas>
But this one is shorter
<tp>
see NEGATE1
<tp>
20000448: 1B9E subs r6 r3 r6
<tp>
2000044A: 4770 bx lr
<tp>
Bytes: 6 ok
<tp>
20000446: 2300 movs r3 #0
<veltas>
My NEGATE is 4 bytes, not including the CREATE entry
<tp>
negate is 4 bytes
<tp>
seems efficient enough
<tp>
of course youre on a 8 but cpu, this is 16 bit opcodes
<veltas>
In Z80 assembly it's something along line of: XOR A LD H,A LD L,A POP DE SBC HL,DE PUSH HL JP forth_next
<veltas>
Which I believe is 10 bytes at a glance
<veltas>
And extra code in the stack-checked version (my stack checking is done per-CODE def)
<tp>
yeah always overheads
<tp>
mine is the 0000207E: 4770 bx lr
<tp>
basically it's only one instruction "negs"
<veltas>
Z80 has a 'negative' instruction, but of course it's 8-bit and applies to A only
<veltas>
Actually I'm sure you knew that already
<tp>
i suspected, it's been 30+ years since I wrote Z80 assembly
<siraben>
Ah, glad to see discussion on Z80 :)
<siraben>
It's still around these days, with all the high schoolers and college students using TI-84+ calculators.
<veltas>
If I had used HL as top-of-stack then it would be EX DE,HL XOR A LD H,A LD L,A SBC HL,DE JP forth_next
<veltas>
But that's only 1 byte less (I think?)
<siraben>
Unfortunately TI upped their RSA signing on the newer calculators, so people can't flash their custom OSes or sign binary apps anymore :(
<siraben>
Z80 is very register constrained, but I managed to get it to work even using a register for TOS.
<veltas>
I tried with HL as TOS, and did not like it
<siraben>
veltas: How come?
<siraben>
I never checked to see if it gained me anything, it would be too painful to rewrite it at this point, perhaps.
<veltas>
Just over-complicated the situation, didn't gain me much, that was my very unscientific analysis
<veltas>
I think you probably want HL as TOS for max performance, but I am not trying to write the fastest Forth, just keeping it simple
<veltas>
Well I really don't care about max performance because I have a tokenised Forth...
<tp>
good idea, keep it simple to get it going, make it faster later
<veltas>
I have been optimising for space because that's actually *why* I tried Forth out in the first place
<veltas>
The hope of decreasing code foot-print, and then I would just write stuff in assembly that needed speed optimising. That's the idea, give myself a nice big playground, without too much performance penalty in the end
<tp>
veltas, resident Forth cannot compete with C for rom space
<veltas>
Because of CREATE overhead?
<veltas>
Or what?
<tp>
veltas, if you want minimal space and the interactivity of forth, a tethered Forth may be the answer
<veltas>
We'll see if you're right ;)
<tp>
mainly because of the actual Forth code, but yeah the Forth overheads as well
<tp>
it's not my opinion, it's the results of my tests
<tp>
and it's perfectly logical
<veltas>
Forth has a *much* lower minimum commitment than hand-written assembly, and the C compilers I've seen for Z80 are worse at Z80 than me without even trying to golf it
<tp>
heh
<veltas>
Because Z80, to be fair, is not an easy fit for C
<tp>
aha
<siraben>
Yeah, C to Z80 compilers suck.
<tp>
it's still going to have much smaller code
<siraben>
Probably, the lack of registers means you'd need a top of the class register allocation compiler, and even then it's no guarantee since you can easily have more live variables than registers.
<tp>
your Forth will take how many bytes, 12kB ?
<veltas>
tp: Not sure I think it will definitely be under 8KB even with lots of unnecessary stuff in it
<tp>
ok 8kB
<veltas>
I'm at 3KB right now but probably half the words I need, haven't gone too crazy trying to refactor
<tp>
if a assembly blinky takes 80 bytes of machine code, a C one might take 100 ?
<veltas>
Yes but what if you are going to fill the whole RAM with code and data
<tp>
a Forth one will take probably 90 bytes ?
<veltas>
What is a blinky?
<tp>
but the Forth binary will take 8kb plus the blinky of 90 bytes compared to the C one of 100 bytes ?
<tp>
it just flashes a LED on your board
<veltas>
Basically, Forth's words I will be compiling into definitions at 1 or 2 bytes each if no special compilation semantics.
<tp>
a tethered Forth with a multipass compiler may do the blinky in 80 bytes also
<veltas>
The words in Forth are a higher level than what Z80 does, they're mostly 16-bit logical programming operations like looping, arithmetic, comparison, etc
<veltas>
To do those things in Z80 requires an unexpectedly larger amount of code
<tp>
but the tethered Forth only produces a blinky binary it has nothing else resident on the chip
<tp>
veltas, wasnt the Z80 designed to be C friendly ?
<veltas>
No I don't think so
<tp>
or is that the Atmel Mega9 ?
<veltas>
I think it was designed to be an 8080 with extras
<tp>
ahh, ok i'm getting chips mixed up
<veltas>
It's (mostly) backwards-compatible with native 8080 code
<tp>
yeah, definitely very intel like with the register banks
<tp>
I didnt have any problems with assembly on it
<tp>
but Ive never liked intel ISA as I started the motorola 6800 assembly
<veltas>
: BLINKY ( -- ) BEGIN 0 ATTR-FILE ! 25 MS $3F ATTR-FILE ! 25 MS 0 UNTIL ; \ this would be 20 bytes + CREATE overhead
<veltas>
At a glance
webchat9 has joined #forth
<veltas>
That is blinking the first colour attribute cell, because there aren't any LEDs but it would be roughly the same code for a different address or port if there was.
<tp>
do you have a PIO on the spectrum ?
<veltas>
Yes
<tp>
cool
<veltas>
Wait you mean port input/output?
<veltas>
Or something else?
<tp>
yea
<veltas>
better: : BLINKY 0 BEGIN DUP ATTR-FILE ! 25 MS INVERT $3F AND 0 UNTIL ; \ about 16 bytes
<veltas>
tp: How would you do an infinite loop in Forth?
<tp>
a few ways, usually a do loop when Im testing
<veltas>
I hope BEGIN .. 0 UNTIL is alright, seems like the simplest one
<tp>
infinite loop in the finished project may be a begin 0 until as you say
<tp>
mostly it's begin key? until
<tp>
so a keyboard hit stops the loop
<veltas>
Yes that is a good point
<tp>
sure BEGIN .. 0 UNTIL is fine tho
<veltas>
I am implementing KEY? at the moment
<tp>
my touch sensor will be the reset button on my new test jig as I wear buttons out
<veltas>
What if you wear your capacitor out?
<tp>
my process requires a reset with every non recoverable bug
<tp>
hahaha, the piece of pcb ?
<tp>
easy to replace
<veltas>
I am of course joking
<tp>
og course
<tp>
and it's not impossible I could wear it out
<tp>
id wear thry the insulating plastic first tho
<tp>
i did think about a magnet and hall effect switch but thetouch sensor is fine
<veltas>
tp: I plan to try and set up the Forth so you can keep the dictionary contents seperate from CREATE info, so you just get a big Forth blob without word names etc
<veltas>
As an option when building the Forth
<tp>
and save a lot of space ?
<veltas>
Yes hopefully
<veltas>
So not quite as optimised as the tethered one, but should enable you to at least get rid of all the unnecessary word strings
<tp>
sure
<tp>
but youll use your interactivity ?
<veltas>
Yes
<tp>
whats the main reason for requiring smaller binary code ?
<veltas>
The plan is this: you can build the program, and then it will just run on its own as long as you don't QUIT if you just 'leave out' the CREATE area
<veltas>
tp: The main reason is I want to see what I can do with 48K so am trying out some fancy ideas
<tp>
aha
<veltas>
I don't know how successful this will be but I already like the tools I've gained with this Forth
iyzsong has quit [Ping timeout: 256 seconds]
<tp>
yes, Forth is fabulous for too building
<tp>
thats become a lot of the fun for me
<tp>
veltas, so when you write assembler for the z80 where does it run from, ram or eprom
<veltas>
RAM
<veltas>
Because I'm targeting the ZX Spectrum, so the ROM is the Sinclair BASIC ROM
<tp>
and if you need to make it nv only tape ?
<veltas>
Yes
<tp>
bi eprom option ?
<tp>
no eprom option ?
<veltas>
No
<veltas>
Changing the ROM on a Spectrum is not hard but I am targeting vanilla hardware
<veltas>
So this is a pure software exercise
<tp>
when I had a 8085 dev kit (SDK8085) it came with ram only as well
<tp>
it had a hex keypad and 7 seg leds displey
<tp>
so I programmed by hand in machine code
<tp>
but I needed eprom to make my devices which I sold in those days
<MrMobius>
tp, the 8-bit AVRs were designed to work well with C
<tp>
because I didnt have any software, I added a large rotary switch which simply switched the address and chip select lines between the ram and eprom
<tp>
MrMobius, yes, I remembered that after veltas said it wasnt the Z80
<tp>
veltas, and the dat lines of course
<tp>
vel so Id develop on ram tiil it was good to go, rotate the switch to eprom and a small program burnt the ram to eprom, no relocator needed
<veltas>
Cool
<tp>
MrMobius, after looking thru the STM StdPeriph library I must admit, it's pretty easym but still to abstracted for me. It did give my some idea why people have so much trouble grasping the config of periperals tho
<tp>
MrMobius, and it also gave me some extra insight int problem areas I've encountered with various peripherals
<MrMobius>
tp, ive only had to mess with it once and the config is definitely tough
<tp>
MrMobius, now i have a nice doxygen webpage with all that stuff it's a big bonus for me
<tp>
great for insight into the perepherals as they even have a lot of useful notes
<tp>
and they do much as I do, multiple lines for bitfields
<tp>
MrMobius, so the discussion we had has been very beneficial for me and I appreciate you pov
MrMobius has quit [Ping timeout: 260 seconds]
reepca has joined #forth
<veltas>
tp: Part of why I keep capitalising my Forth is because I am writing dictionary defs manually and I have chosen caps as the canonical stored names for words
<veltas>
So it's become a proper habit now
<veltas>
But I might start writing lower-case when I have my interpreter working *shrug*
<tp>
veltas, Im sure it's no problem. quite a few people here use CAPS for Forth code
<veltas>
I do prefer looking at lower-case Forth
<tp>
it doesnt bother me
<veltas>
I really liked how the gforth examples looked
<tp>
yeah I have everything in lower case across the board here except capitals for text
Vedran has joined #forth
Zarutian_HTC has quit [Ping timeout: 250 seconds]
MrMobius has joined #forth
<crest>
does mecrisp stellaris have reliable tail call optimization or stack *over*flow detection?
<crest>
because i tried to loop over the dictionary in a (tail) recursive word and crashed the system with "unhandled interrupt 3"
<crest>
i replaced the (not really) tail recursion with a begin/until loop and it works