<ptrkriz>
I don't seem to get the same output at all
<ptrkriz>
when I press "n" I get "noname Code"
<ptrkriz>
and it freezes
mtsd has joined #forth
<ptrkriz>
nvm, doesn't freeze, but nothing happens whatever I input
<ptrkriz>
any clue why?
<ptrkriz>
also why can't I proprly disassemble a word using "see"? I am expecting asm like I do with swiftforth... I do get asm when I use "disasm" or "discode" but no clue how I get the addr and what the "n" should be (params to discode)
Zarutian_HTC1 has quit [Remote host closed the connection]
<inode>
ptrkriz: the singlestep debugger only works for me if invoke gforth as gforth-itc, otherwise i am presented with "Invalid memory address" and a backtrace - the first line of that page mentions "The singlestep debugger works only with the engine gforth-itc."
<ptrkriz>
oh you are right, I missed that
<ptrkriz>
what's itc? I'm new to forth
<inode>
indirect threaded code
<ptrkriz>
ah I see
<ptrkriz>
thanks
<ptrkriz>
sometimes it says "compiled" when I define a word, and then it starts doing it every time
<ptrkriz>
not sure whats up with that
<inode>
also you can't expect to see disassembled instructions for words that are composites of other forth words, you'll always get the forth code back, but you can get the execution token of such a word, dump the memory at the address, and try to make sense of the structure if you wanted
<inode>
eg. see rot vs. see badword
<ptrkriz>
yeah, how do I get the memory address of it, or how do I dump it?
<ptrkriz>
and yeah I noticed that just a few mins ago
<inode>
' badword hex 100 dump
<ptrkriz>
hmm how would I disasm or discode it tho?
<ptrkriz>
how do I know the "n"?
<inode>
that's just the length of the range to disassemble
<inode>
this dump doesn't appear to contain valid instructions anyway, but that's not say the first machine word's worth of bytes aren't an address of an interpreter though
<ptrkriz>
inode: and what's up with this "compiled" thing with gforth?
<ptrkriz>
[ 32 1 - ] literal lshift compiled
<ptrkriz>
then whatever I input, it says compiled
<ptrkriz>
[ 32 1 - ] literal lshift compiled
<ptrkriz>
.s compiled
<ptrkriz>
I read "It's probably also worthwhile to change `32 FRAC – lshift` to `[ 32 FRAC - ] literal lshift` for a similar reason." so I wanted to try it out
<ptrkriz>
so not sure how that works
<inode>
[ ] aren't really useful outside of word definitions, [ enters immediate mode so you can calculate the result of something to include in your definition and ] enters the compilation state
<inode>
so gforth assumes you're still compiling, until you give it ; or some error occurs and it tries to get back to some sort of sane state
<mark4>
[ enters interpret mode and ] enters compile mode
<mark4>
not immediate mode
<mark4>
: foo forth code here [ some math calculate here ] literal blah blah ;
<inode>
^ what he said
<mark4>
the switch from compile back to interpret allows you to do some calculation of some value at compile time instead of run time and compile it as a literal
<mark4>
and "literal" is an immediate word so even though its after the ] and you are back in compile mode it compiles the value you calculated as a literal
<mark4>
as for the "compiled" thing with gforth i dont use gforth, you couldnt PAY me to use a forth written in C
<mark4>
forths written in C are an abomination imho
<inode>
why target C specifically? surely your distate includes forths written in any language higher than assembly?
<inode>
distaste*
<mark4>
any non trivial application written in C will be 100 times larger than the euqiv forth
<MrMobius>
it will probably be smaller than Forth
<mark4>
if you write a forth for android in java im not going to like it but i probably wont hate on it the way i hate on C based forths
<inode>
the same thing can be said for most lanauges
<mark4>
no i can guarantee it wont be
<mark4>
MrMobius, how big is the libncurses library?
<ptrkriz>
mark4: what do you use?
<MrMobius>
mark4, it's difficult to write more than a line or two of unoptimized forth that is smaller than the equivalent optimized C
<inode>
languages*, just the number of times larger in the source language changes
<MrMobius>
mark4, I have no use for that in embedded so I couldnt tell you
<mark4>
i use my own forths
<mark4>
MrMobius, its about 500k in size. my more powerful (tho being rewritten now) forth version of it was 8k
<mark4>
forth is orders of magnitude more space efficent than C is
<cmtptr>
do you have a forth library that does everything libncurses does to comare it to?
<cmtptr>
+p
<mark4>
for NON TRIVIAL applications
<ptrkriz>
mark4: for x86_64?
<mark4>
for a few lines there wont be that much difference
mark4 has quit [Remote host closed the connection]
<ptrkriz>
altho I wanna get a board
<MrMobius>
did he rage quit?
cox has joined #forth
cox is now known as mark4
<cmtptr>
i don't think so, he just does that
<cmtptr>
see, he's back
<mark4>
sorry internet problems
<MrMobius>
there he is
<mark4>
did i miss a reply? lol
<cmtptr>
no we definitely weren't talking about you behind your back
<MrMobius>
no I waited for youto return lol
<mark4>
kk
<mark4>
im a forth zealot and i HATE the c programming language
<mark4>
i have a forth buddy that says
<mark4>
"Developing embedded applications in C is like opening a can... WITH A ROCK!"
<MrMobius>
I'd have to see exactly what the library is doing but it's doubtful an 8k forth library is doing the same as a 500k C library
<mark4>
smash smash smash... gets the job done
<ptrkriz>
mark4: is your stuff for x86_64?
<mark4>
well you can see the old version of it at mark4th/x4 on github
<MrMobius>
I tested this for the 6502 and Forth is easily 3x bigger than the C version and that is not even that good at optimizing
<mark4>
i just ported most of x4 to x64 on github :)
<inode>
anyone know if there was any more development into WISC (writable instruction set computing) systems beyond CPU/32?
<mark4>
MrMobius, which 6502 forth?
<mark4>
what is a writeable instruction set?
<mark4>
ESP32 has user opcodes but thats the manufacturer who sets them
<cmtptr>
we should hold a #forth tournament: come up with some set of problems, and the forth zealots can write solutions in forth and those of us who like forth but also like other languages too can write solutions in other languages, and then we can debate for the rest of eternity over who won!
<MrMobius>
mark4, Tali Forth 2 which is an STC forth. creates much bigger programs than C and is around 20% as fast
<MrMobius>
although by far the fastest forth I have been able to find
<inode>
mark4: an architecture that allows you to implement microcode that suits your desired programming language better than an assumed general purpose instruction set would, so that's at least what the premise was iirc
<mark4>
MrMobius, i might suggest that the 6502 forths you are using are maybe not verey good? :)
<MrMobius>
mark4, that's a backwards way of reasoning. shouldnt you look at the forths first without assuming that?
<mark4>
inode end users can modify the opcodes at compile / run time? or its an ARCh and the producer who licenses it can define opcodes?
<inode>
mark4: the former
<mark4>
thats basically what the extensia arch does which is what the ESP32 is based on
<mark4>
im writing an esp32 assembler in forth its about 99% complete
<MrMobius>
inode, I suggested that more than once but there were no takers at the time. hard data on C vs forth seems to be exceedingly rare...
<mark4>
MrMobius, maybe but even my 8051 forth was only 3k in size total
<mark4>
my av4 forth was 4k but it had a lot of fat in there thats not really needed
<inode>
MrMobius: what would you consider to be good points of comparison?
<MrMobius>
how many cycles it takes to execute and how much space it takes
<mark4>
also, even if the forth was perfect the application implementation might not be
<MrMobius>
other things will mostly be opinion, so no objections if you like using forth even though its slower or you dont need it to be fast
<mark4>
MrMobius, im actually trying to devise a more efficient way of implementing structures in my forths, my 8k curses code could be 2k if i can do it
<MrMobius>
mark4, size of the kernal is one thing but the size of the resulting programs is what I mean by size
<mark4>
yes
<cmtptr>
MrMobius, i've never used it in anything serious but i always imagined i'd treat it like a scripting language: great for rapid prototyping and just getting the damn thing to work, and then you come back afterwards and optimize critical paths with code words
<mark4>
and application code size depends on many factors
<inode>
MrMobius: fair enough, with these sorts of tests i wonder how you can eliminate the skew of the differences in quality between both languages
<mark4>
Cm says if its not at least 100 times smaller than the equiv c its not forth :)(
<mark4>
there are also MANY ways to skin a cat
<inode>
MrMobius: fair enough, with these sorts of tests i wonder how you can eliminate the skew of the differences in quality between both languages *compilers*
<MrMobius>
I doubt that was true even in the good old days before optimizing C compilers
<mark4>
im not sure a STC forth is as space efficent as a DCT
<mark4>
or ITC
<MrMobius>
mark4, right. I would think it would be least space efficient but fastest (though also depends on architecture)
<mark4>
yes thats the tradeoff
mtsd has quit [Remote host closed the connection]
<MrMobius>
but the fastest model is still 5x slower than C, at least in the comparison I did
<mark4>
btw, when i showed what my curses lib could do to the ncurses dev he said that would be almost impossible in ncurses
<mark4>
i had multiple overlapping, moving windows with text scrolling in any direction
<mark4>
but im rewriting it to support utf8 now
<MrMobius>
inode, my take is that the quality of compiler is irrelevant. we can only test what exists. if something better could exist but doesnt, it's irrelevant until someone implements it
<MrMobius>
ie performance could be much better if more forths optimized but a lot of platforms dont have an optimizing forth
<mark4>
i dont actually see ANY need in the real world for optimziation down to the opcode level when the base language is naturally efficient
<mark4>
C without optimizations is HORRENDOUSLY inefficient
<mark4>
one look at the output of GCC at -O0 will show that
<mark4>
yes you can eek out a bit of performance optimizing at the opcode level but you get orders of magnitude better performance improvements simply by optimizing the way you do something
<MrMobius>
why does that matter? people generally have optimization enabled unless there's a good reason not to. -O0 is not a useful indication of anything
<mark4>
you heavilly optimized bubbles sort will be significantly slower than my unoptimized shuttle sort
<mark4>
and shuttle is just one step up from a bubble lol
<MrMobius>
mark4, but what happens when you get orders of magnitude better performance by optimizing the way you do it and it's still not fast enough? in that case you can do things with C that you cant with forth if there is still performance left that you need
<mark4>
MrMobius, i was developing an android NDK forth for armv7-a but was doing part of the JNI in C
<mark4>
optimized to -O3 or -O2
<mark4>
the code was HORRIBLE and im just talking 2 or 3 wrapper functions in C
<mark4>
like 2k total
<mark4>
i rewrote them in FORRh and got them down to less than 1k
<mark4>
C does not naturally lend itself to space efficiency
<mark4>
i wont question its speed efficiency
<MrMobius>
did you try it with -Os?
<mark4>
but... you almost NEVER need that kind of efficiency everywhere
<mark4>
yes
<mark4>
theres actually only a few small tweak differences betwen 2 and s optimization
<MrMobius>
sorry but you cant say you almost never need that kind of efficiency. that is highly dependant on what youre doing. you cant generalize that other people will use the languages for the same thing as you
<mark4>
MrMobius, ALMOST never. not NEVEr
<MrMobius>
its not even almost never
<MrMobius>
-Os is for size not speed
<mark4>
now. if you are writing world of warcraft you probably want the game engine pretty efficient :)
<inode>
mark4: how were you gauging these sizes? entire resultant object size? or copying out the bare minimum required?
<mark4>
its for size i know
<mark4>
inode what ever the code size is within the resultant opbject well code and data use
<mark4>
i can pretty much beat any c compiler out there for space efficiency
<mark4>
and i dont consider myself 'expert"
<mark4>
i simply do not worry about speed efficiency accross 90% of my code. only in those places where its absolutely necessary
<mark4>
which after 30 years of embedded code are very rare
<mark4>
inode with my curses i look at libncurses.so and compare that to my 8k of used code space :)
<mark4>
ya i know a lot of that .so is glue stuff thats not part of the loaded image
<mark4>
with the arm64 abi i would say pretty much ANYTHING that does not follow it will be orders of orders of orders of magnitude smaller
<mark4>
2/3 of your code on aarch64 is going to be moving data from one register to another
<MrMobius>
ya thats usually the point people make when you crticize performance. recode the critical 10-20% in assembly 0_0
<mark4>
mov x, y mov a, b mov c, d ..... call function .... unwind those moves
<mark4>
MrMobius, yes
<mark4>
i never critisize performance, if you dont need it i dont waste my time giving it
<MrMobius>
so I guess it's a matter of preference if you'd rather do that or just write 100% in C
<mark4>
but you often do not know where you really need it till you try
<mark4>
99.9999999% of my career is C based :)
<MrMobius>
true but you also don't have to worry about that at all if you write in C. all that's left to think about is the algorithm
<mark4>
so naturally i pick -O2
<mark4>
except C is never... absolutely NEVER space efficient
<mark4>
it gets the job done
<mark4>
but in todays age, space efficiency is less of an issue
<MrMobius>
again, it depends on the architecture. C is about 30% bigger than assembly on 6502 and half as large as the STC forth
<MrMobius>
30% bigger than assembly is pretty space efficient to me
<mark4>
when your $6 development board has 256 megs of ram and 512 megs of flash.. . .
<mark4>
my biggest gripe against C is not is runtime efficiency or its size efficiency
<mark4>
its its development time inefficiency
Zarutian_HTC has joined #forth
<MrMobius>
thats another thing that would be interesting to measure
Zarutian_HTC has quit [Remote host closed the connection]
<mark4>
ya but then again im 100% biased so my devel time in C is never going to be as efficient as my devel time in forth lol
<mark4>
we need to have forth only coders learn C, c only coders learn forth and then measure them against each other lol
<mark4>
p.s. please dont tell my agency or my employers i hate c :)
<mark4>
actually tho my manager knows im a forth fanboi :)
<MrMobius>
that would be interesting
<MrMobius>
I think I would compare the best C coders to the best forth coders
<MrMobius>
or some level of proficiency
<mark4>
my father told me a story taht i ahve not been able to verify but some time in the 1980's general electrics diesel electric division (make diesel trains) was trying to develop an ECU for engine diags
<mark4>
they hada team of devs working on it for years and when the manager said show me what you have they couldnt really demo it
<mark4>
so he hired forth inc and they came in and wrote the code in 2 weeks
<mark4>
i dont reamember the actual time frames of the story and i absolutely CANNOT verify that this story is true
<mark4>
but i believe it may be
<MrMobius>
right this is the type of story you hear a lot
<mark4>
yes
<MrMobius>
and people dont usually come out and say what they are implying because people would immediately criticize them
<mark4>
if i think it i say it and if you have critisism i TRY to listen lol
<MrMobius>
since the point of the story is other languages are so bad that it takes years and youre not finished whereas forth can do it in 2 weeks
<MrMobius>
which ignores all the other hypotheses like the team was just not good at programming
<mark4>
well it was a non trivial problem and i dont think C was a good choice
<mark4>
agreed
<mark4>
there are many variables we dont know even if this story is true
<mark4>
but i worked for siemens PTD (power meters) for a while and they were developing an in house C++ operating system to be used on all future products
<MrMobius>
why would you think C is not a good choice in that story? did your dad say they had limited ROM space in the ECU or something?
<mark4>
their OS filled up 98% of the available code spave
<mark4>
space
<mark4>
do not know what architecture it was. i just do not think C is an embeddable language. even embedded java can be more efficient
<mark4>
you can embed a java in a very small space
<mark4>
you can embed a forth in a very small space
<MrMobius>
at the expense of speed
<mark4>
and forth is naturally space efficient
<mark4>
which is not critical
<MrMobius>
so youre back to not generalizing since project requirements vary so wildly
<mark4>
and when it is... asm to the rescue
<mark4>
yes and no
<mark4>
im generalizing 30 years of experience :)
<mark4>
yes there are times when being efficient is critical
<MrMobius>
seems like a very bad idea :)
<mark4>
thats a very very small percentage of any applictions code
<MrMobius>
depends on the application
<mark4>
i think being more space efficient is more important than being speed efficient 99% of the time
<mark4>
when speed is critical you can code asm
<MrMobius>
wait, werent you the one just saying megabytes of space for $6???
<mark4>
oh wait. nobody does that any more because "asm is not portable" bullshit lol
<mark4>
MrMobius, yea thats true TODAY lol
<mark4>
but we are using PIC32's here at cox and were 90% full and have a library that we need to add thats going to eat up about the same space
<mark4>
but were not using the MIPS16E optimization because we have to pay for that version of microchips compiler
<MrMobius>
ya I aggree thats a shame
<MrMobius>
I dont know why they do that
<mark4>
so... we have used up over 200k of code space on an application I could have written in forth in much smaller a space
<mark4>
err except that library which thers no way i could rewrite lol
<MrMobius>
they must have run the numbers and figured out the business they are chasing off is less than the profit they get from selling gcc
<mark4>
thats a full CAN stack lol
<cmtptr>
c doesn't have to be like that, though. i think a lot of language debates are probably really about culture underneath
<MrMobius>
not sure it's allowed at your work but you know you can get a fully optimizing version of gcc for free?
<mark4>
you can
<MrMobius>
I think microchip has to give you the source if you ask since its gcc. the MaxiMite or whatever it's called guys have a copy you can use
<mark4>
its open source but compiling the microchip c compiler from sources is a HUGE pain
<mark4>
so almost nobody has done it
<mark4>
it is open source but its not as simple as downloading and running make :)
<mark4>
and... if you get it wrong, even if you enable the 16 bit opcode optimization you have a almost working compiler for production code?
<mark4>
erm no. just pay for the one by microchip lol
<mark4>
thats where tye get you
<mark4>
they
<mark4>
i would much rater see a forth from forth inc here
<mark4>
i could teach everyone here forth and develop the entire application other than the can bus stuff from scratch in less time than its taking us to do this in C lol
<mark4>
its not rocket surgery
<mark4>
really
<mark4>
the ONLY non trivial bit of this entire project is the CAN stack and... were not evne using that part yet
<MrMobius>
that will be fun
<mark4>
well it "would" be fun lol
<MrMobius>
having everyone share the same global/local variables
<MrMobius>
namespace clash engage lol
<mark4>
that only happens with bad coders and that can happen in any language :P
<mark4>
thats why forht has vocabularies and headerless words
<MrMobius>
no it cant
<MrMobius>
it doesnt happen in almost any other language
<MrMobius>
like in C it doesnt matter what I name my local variables. you can reuse those names in your functions
<mark4>
forth does not have local variables at all unless you add a horrible extension to add them
<mark4>
and global variables and functions can be made headerless when they should not be public
<MrMobius>
depends. Leo Brody brags about "local" variables which in all other languages would be called "globals"
<mark4>
if you name your shit properly there will be NO namespace collisions
<mark4>
a local variable is stack based - forth stack items are not named
<mark4>
a named variable is in heap and can be a) properly named or b) made headerless
<MrMobius>
hmm, so youre talking about everyone having their own vocabulary and each person contributes only their chunk of headerless code to the combined project?
<mark4>
no
<mark4>
if you have an NVM lib and you have a UART lib and a foo lib and a bar lib
<mark4>
you can prefix all your global functions with the module name
<mark4>
you can put EVERYTHING in the same vocabulary
<mark4>
OR
<mark4>
you can create a nvm voc a uart voc a foo voc and a bar voc
<MrMobius>
mark4, no, thats not what he desrcibes in Starting Forth. a local variable is not on the stack. internally it uses ALLOT and is part of the dictionary. it's what he recommends if you have too much on the stack and arent going to PICK
<mark4>
but you should still properly name your functions within the vocs
<mark4>
local to him means in close proximity to the code that uses it lol
<MrMobius>
what do you name the variables that the functions use? vocabulary_function_temporaryvariable?
<mark4>
nothing
<mark4>
they are items on the stack and have no names
<MrMobius>
and when the thing you need is 4 levels deep?
<mark4>
if i have a ring buffer head pointer and tail pointer and count i might call them ring_head ring_tail or something
<mark4>
im actually a bit lazy about this most times lol
<MrMobius>
and if I have a word that also uses ring_tail?
<mark4>
what do you mean 4 levels deep?
<MrMobius>
I mean if I put 4 pointers on the stack and then have a loop that needs to access each of the 4 in turn, how do I do that without using variables?
<mark4>
2dup ?
<mark4>
or 4dup if you need it
<MrMobius>
and if later its 5 or 6 i should make a 5dup and 6dup word?
<mark4>
or you dont do A B C D then do 4 operations but do A a-op B b-op C c-op D d-op
<mark4>
then you need to rethink your forth
<mark4>
CM says you should try never need to access items on the stack deeper than 3
<mark4>
but
<mark4>
you do have PICk
<MrMobius>
so there are no problems where you would need to access 6 pointers in turn?
<mark4>
0 pick is a dup
<mark4>
1 pick is an over
<mark4>
2 pick ... N pick
<mark4>
you can make a copy of the Nth stack item and use it
<MrMobius>
isnt PICK something we're encouraged to avoid?
<mark4>
yes
<mark4>
but thats a RULE OF THUMB
<mark4>
rethink your order of operations so you dont need the 4th or deeper stack item
<MrMobius>
so you would use PICK instead of putting one of the 4 in a variable and using ROT for the other 3?
Zarutian_HTC has joined #forth
<mark4>
im not anti variable
<mark4>
if thats a good solution use it
<MrMobius>
what if that's not possible? what if I need to access all 4 pointers because im outputting to a screen for example?
<MrMobius>
so then you do need variables in some cases and they do need to be local variables not just everything on the stack
<mark4>
2>r do something with the 2 items now at top of stack then 2r> and do something wth those
<mark4>
if you need to do it non destructively
<mark4>
2>r 2dup do-stuff 2r> 2dup do-stuff
<mark4>
but again. if your code is so complex it needs to access past the 3rd stack item it might be more efficient code if you rethought it
<mark4>
NOT always easy and if stack juggling works....
<MrMobius>
maybe but you have to admit there are plenty of cases where that's just not possible
<MrMobius>
you might need a lot more than 6 pointers at once
<mark4>
but if your code is chock full of 2dup 2>r 3dup blah blah you absolutely need to rethink
<mark4>
no. thers never a place where you cannot rethink your methods.... there ARE cases where thats not an option though :)
<MrMobius>
the point is, you can get to a point I reached quickly in forth where you have a lot of 2dup 2>r nonsense and then refactor, refactor, refactor and are still stuck since there are problems where those two things will never solve it
f-a has joined #forth
<MrMobius>
so you have to rely on variables, which is usually the best thing in my opinion if rethinking doesnt work
<mark4>
actually even in C i have found non trivial optimizations simply by doing that re-factor
<mark4>
yes but those variables do not need to be visible to the reste of the app
<mark4>
in my forths i have <headers (from headers) to go headerless and headers> (headers to) to go headerfull
<mark4>
the headerless headers all exist right up until you
<mark4>
behead
<mark4>
then they are all gone
<MrMobius>
so basically you define a variable, use it in a word, then remove its head so other words can reuse the variable name?
<mark4>
yes
<MrMobius>
thats smart
<mark4>
i also do the same with functions
<mark4>
like in my assembler
<MrMobius>
also tremendously wasteful of memory but you may not care about that
<mark4>
where i have multiple opcodes that have the same encodingd except for one little bit i crate a compiling word for those opcodes
<mark4>
: foo: ... ... ... .. comma ... .. ;
<mark4>
123 foo: fud
<mark4>
234 foo: blah
<mark4>
foo: is headerless but the words i compile with it for the assembler are not
<mark4>
one of the extensions im planning
<mark4>
is a transient vocab that i can compile all words that are only needed at compile time
<mark4>
i.e. compile the CODE for those words into a separate buffer, not just the headers
<mark4>
then i can discard the code AND the headers for those words
<MrMobius>
why the code? are you inlining it from the buffer?
<mark4>
for example the above assembler opcode creating words
<mark4>
the word i use to CREATE an opcode is not used when i USE that opcode
<mark4>
well unless its a does> word but even that can be refactored you dont NEED to use does> foo
<mark4>
for example
<mark4>
: constant create , does> @ ;
<mark4>
or
<mark4>
: doconstant .... ;
<mark4>
: constant create , ;uses doconstant ;
<mark4>
so wheere i have a word in the assembler that just creates a bunch of nemonic words that have similar encoding that creating word is never used in the assembler itself
<mark4>
when you use those opcodes the word that created those opodes is deadwood
<mark4>
another example
<mark4>
struct: foo ...... ;struct
Zarutian_HTC has quit [Remote host closed the connection]
<mark4>
in my forth, all the items between struct: and the ;construct are created as CONSTANTS
<mark4>
those constants are utilized in the code that references that structure but
<mark4>
erm missed some info
<mark4>
i have variable foo and constant foo but i also have var foo and const foo
<mark4>
var is like value
<mark4>
but const creates a state smart immediate
<mark4>
so 0 const foo will create a word called foo that will compile itself as a literal
<mark4>
: blah .... foo .... ; would be the same as : blah .... [ foo ] literal ;
<mark4>
so... the definition for all those constants are NEVER actually referenced at run time
<mark4>
and for any code that uses a lot of structures.... that leaves a lot of deadwood i would like to be able to strip
iyzsong has quit [Read error: Connection reset by peer]
<MrMobius>
inserting the literal like that is really smart
<MrMobius>
I solved some of those problems with a python script
<MrMobius>
123 const foo
<MrMobius>
then all mentions of foo are replaced with 123, so nothing takes any dictionary space
<MrMobius>
begin_vars var foo var bar end_var
iyzsong has joined #forth
<f-a>
what is this “python” you are talking about?
<f-a>
( ͡° ͜ʖ ͡°)
<MrMobius>
which becomes CREATE vars1 2 CELLS ALLOT
<MrMobius>
then any reference to foo becomes [ vars1 0 + ] LITERAL and bar becomes [ vars1 2 + ] LITERAL
<MrMobius>
and variable usage goes from 2k down to only 90 bytes
<mark4>
ya
<mark4>
if you look at forth inc's STC code their optimizer converts all constants into an immediate move into a register
<mark4>
mov r0, 0x1234
<mark4>
if you look at t4 thats what i do there to
<mark4>
thats not a compiler optimization in my mind
<mark4>
im not changing the underlying code structure
<MrMobius>
it may not be an opitmiation at all if it's followed by mov r6,r0 :)
<mark4>
i dont do compiler optimizations, ill do things efficiently in the compiler but i wont change what you put
proteus-guy has joined #forth
<mark4>
i toyed with the idea of doing a peephole but... meh
proteus-person has joined #forth
<MrMobius>
I thought you said once your compiler optimizes? maybe you meant something different
<mark4>
no i dont optimize ever
<MrMobius>
ahh ok
<MrMobius>
I think a lot of slow down comes from not recognizing constants at compile time in forth
<MrMobius>
like : lshift5 5 lshift ;
<MrMobius>
or even better : lshift7 7 lshift ;
<mark4>
i HATE the words lshift and rshift lol
<mark4>
<< >> is what i call them
<mark4>
and u>>
<MrMobius>
youre always shifting by a contant number but most forths will just treat that the same as shifting by an unknown number
<mark4>
its like why dont we call @ "fetch" and ! "store"
<mark4>
because thats not forth
<mark4>
if you cant read << and >> as shifting operations... . . .
<MrMobius>
so if youre on an 8 bit system without a barrel shifter, you get a loop with a compare and 7 left shifts which eats up 100+ cycles
<mark4>
yes >> and << and u>> all take a parameter
<MrMobius>
whereas a C compiler would recognize that shifting left 7 is faster if you swap bytes and shift once
<mark4>
if the parameter is ONE you use 2/ or 2* ur u2/
<MrMobius>
wihch is 10-20x faster
<mark4>
and that trivial amount of performance improvement is... negligable
<MrMobius>
again, depends on the application. it is not negligible when those start adding up and that's something you need to be fast
<MrMobius>
that and a bunch of other little things that slow forth way down
<mark4>
then code it the way you want it to be coded
<MrMobius>
anway, just bringing that up as an obvious area yo ucould optimize
<mark4>
dont have the compiler hold your hand and be mommy for you
<mark4>
i can optimize my shift words to account for taht too
<MrMobius>
ok, then optimize this please : foo CONST_VAL lshift ;
<mark4>
i would optimize lshift internally
<MrMobius>
ok how?
<mark4>
except i wont i dont see the need for saving 2 clock cycles out of 300 trillion clock cycles
<mark4>
if shift is greater than 8 move bytes then shift.. as you stated
<MrMobius>
lol its not 2 cycles. its 100s of cycles vs 20 or so
<MrMobius>
every time you use lshift
<mark4>
insignificant
<MrMobius>
nope
<mark4>
unless you are on a 1mhz uC
<MrMobius>
not if thats part of the application that needs to be fast
<mark4>
such as?
<mark4>
show me your application that needs you to save CLOCK cycles
<mark4>
you need to change processor or rethink your code
<mark4>
if your chosen uC is not capable of handling the problem you have a problem
<MrMobius>
hah ok im going to put that on a plaque - "you need to change processor"
<MrMobius>
why put a more expensive processor in there if I could just write it in C and get the optimization for free?
<mark4>
your AVR is great but it cant compete with my ESP32 lol
<MrMobius>
I dont think your boss will like that solution
<mark4>
p.s. i love avr :)
<mark4>
we have that exact problem right now at work :P
<mark4>
if you give me an 8051 with 1mhz clock cycle and it takes 12 cycles per opcode and you give me 8k of flash and you need a full lora wan stack and some HUGE application.... you have no right to get PISSY with me when it wont fit :)
<mark4>
all i can do is say "you need to switch to a more powerful platform"
<mark4>
"but we have millions of dollars invesed in this product!"
<MrMobius>
that's a strawman argument that ignores my point
<mark4>
then you wasted it
<mark4>
start over
<mark4>
maybe to a degree
<mark4>
if you need to eek out clock cycles you are doing nobody any favors
<mark4>
literally
<MrMobius>
are there projects that can be done with a given chip in C but cant be done with the same chip using forth because it's not fast enough?
<MrMobius>
i wouldnt say 5x faster is "eeking" out anything
<mark4>
ive never seen any NON TRIVIAL application done in C that could not be done better in forth
<mark4>
never
<MrMobius>
thats not the question
<MrMobius>
here's another way of asking the question: are there projects where you could do it in forth with a particular chip but could have done it in C with a similar but slower and cheaper chip?
<mark4>
hang on doggie nagging
<mark4>
for trivial applications?
<mark4>
yes
<mark4>
for non trivial applications where an OS is needed ?
<mark4>
NO
<mark4>
never
<mark4>
evn on a 32u4 avr you can put a forth in the boot flash area and leave the rest to the application
<mark4>
in this case you want it to be a teathered forth tho
<mark4>
32u4 has 32k of code space. 8 of that is boot flash
<mark4>
24k for app
<mark4>
i would say a tethered forth would be way better for development time and perfectly capable at run time
<mark4>
you spend more money on development than you do on hardware
<mark4>
a USAF pilot has more money in his training than ANY of the aircraft he might fly costs
<MrMobius>
im talking about speed not flash size
<MrMobius>
surely youre not saying there are never cases where the program being 5x faster makes a difference?
<mark4>
5x faster over 100% of the code? or 5x faster over 5% of the code?
<mark4>
those 5% can be coded to be more efficient
<mark4>
even in an STC forth where the forth is compiled down to pure assembler you can be more efficidnt going to human written assembler
<mark4>
and calling that not portable is utter bullshit
<mark4>
i have never in 30+ years of embedded development seen any application where 100% of the code needed to be at blazing speed
<mark4>
even in games like wow things like the user interface can be coded in LUA
<mark4>
you will never convince me that LUA is even as speed efficient as optimized C :P
<mark4>
ive seen complete access control applications developed in 100% pure embedded java
<MrMobius>
youre dodging the question again
<MrMobius>
im not asking if there are cases where 5x speed up doesnt matter
<MrMobius>
I agree that there are
<MrMobius>
I just find it so strange that forth users usually wont give a straight answer on this
<MrMobius>
like if you ask just about anyone who does python if there are cases where python isnt fast enough they just say yes
<MrMobius>
and it doesnt mean that python is worthless and should never be used any more than admitting that sometimes you need the speed and should use C and sometimes you dont and can use forth
WickedShell has joined #forth
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-person has quit [Ping timeout: 272 seconds]
f-a_ has joined #forth
f-a has quit [Ping timeout: 272 seconds]
f-a_ has quit [Client Quit]
f-a has joined #forth
proteus-person has joined #forth
proteus-guy has joined #forth
<mark4>
i dont call c worthless
<mark4>
i am just saying i have never seen ANY application where forth would not have done the job better
<mark4>
erm non trivial application
* crc
uses `fetch` and `store` instead of `@` and `!`
<mark4>
i know lol
<mark4>
i use
<mark4>
i use << and >> for shifts because those are universally known tokens
<mark4>
i dont need : shift-top-of-stack-right-by-N-bits .... ; in order to be able to read the sources
<mark4>
lshift and rshift are limp wristed names
<mark4>
<< >> u>>
<MrMobius>
i dunno. looks too much like C to be safe
reepca has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-person has quit [Ping timeout: 272 seconds]
f-a has quit [Quit: leaving]
proteus-guy has joined #forth
proteus-person has joined #forth
Zarutian_HTC has joined #forth
gravicappa has quit [Ping timeout: 256 seconds]
gravicappa has joined #forth
Zarutian_HTC has quit [Ping timeout: 240 seconds]
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-person has quit [Ping timeout: 256 seconds]
proteus-guy has joined #forth
proteus-person has joined #forth
Zarutian_HTC has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-person has quit [Ping timeout: 260 seconds]
gravicappa has quit [Ping timeout: 272 seconds]
sts-q has quit [Quit: -- PANIC -- The function `show_irc' expects one argument of type [irc], but it is given one argument of type [unit -> irc].]
zolk3ri has quit [Remote host closed the connection]
zolk3ri has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]