<tabemann>
it's still got a lot of ways to go, but I feel I optimized it pretty well
<tabemann>
optimized for space rather than for speed
<tabemann>
this is code where I want to minimize inlining
<tp>
speed isnt a issue when analysing code is it ?
<tabemann>
yeah
<tp>
especially small embedded code
<tabemann>
I even shrunk the word names for the sake of optimization!
<tabemann>
p rather than parse saves a whole cell per word
<tabemann>
which is important because there will be a lot of words
<tp>
cool, I often use single letters when testing
dave0 has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
iyzsong has joined #forth
jsoft has joined #forth
jedb_ has joined #forth
jedb has quit [Ping timeout: 246 seconds]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
kori has quit [Read error: Connection reset by peer]
cheater has quit [Ping timeout: 264 seconds]
phadthai has quit [Quit: brb]
phadthai has joined #forth
dddddd has quit [Remote host closed the connection]
cheater has joined #forth
dave0 has quit [Quit: dave's not here]
rdrop-exit has joined #forth
<rdrop-exit>
hello knights of the Forthdom
<tp>
greets he that tilts at onboard forths !
<tp>
rdrop-exit, just the parson I wanted to see!
<rdrop-exit>
I'm not a parson
<tp>
(spoken in a Irish accent)
<rdrop-exit>
:))
<rdrop-exit>
what's up?
<tp>
rdrop-exit, I'm doing a doc page on the differences between configuring a cortex-m peripheral (in this case the system clock) with Keil C and Forth
<rdrop-exit>
you're so obsessed with c
<tp>
this is the first time Ive looked at a modern system like Keil who are considered a leader in the embedded C space, and in fact owned New York ARM holdings
<tp>
oops
<tp>
-New York
<tp>
(how did that get in there?)
<rdrop-exit>
:))
<tp>
well I spend a lot of time debating with C users as C is the defacto standard in embedded
<tp>
Forth is barely known in the embedded space, so the debates are quite understandable
<rdrop-exit>
I don't bother, I'm just happy I learned Forth before C
<tp>
plus, unfortunately, C is also the defacto example and often the defacto explanation for how hardware works in the ARM documentation
<phadthai>
"portable assembler" :)
<phadthai>
even if it never was completely that
<tp>
it's a bit like kids go to school to learn how to use a computer, but all they learn is Microsoft Word, Excel and Powerpoint
<rdrop-exit>
C as its place as the lingua franca of the UNIX/POSIX world, but I agree with you on code examples for embedded, they should only give a C example as a supplement to a asm example, not instead of an asm example
<phadthai>
"But can it do Youtube?"
<tp>
as tho somehow learning three microsoft apps embodies "using a computer"
<tp>
hahahah
<tp>
rdrop-exit, exactly, but even a ASM example can be a bit hll, sometimes a description, a truth table etc is all thats needed
<rdrop-exit>
it reminds me of the IBM mainframe world, they had their own worldview and jargon, it was difficult to get an IBM mainframe guy to think outside that box
<tp>
personally Im opposed to the use of a programming language to explain how hardware works, I think it is a cheap and lazy cop out
<rdrop-exit>
I agree
<tp>
sure, I think it's understandable, a bit like expecting a foreigner to understand your parochial slang, even if it's 'based' on english
<rdrop-exit>
right
<tp>
naturally, this process is a human condition, and requires a special mentality or training to overcome it's inevitable use
<tp>
take the Chrysler 'lean burn engine' development in the 70's ?
<tp>
at one point, nobody from the electronics engineering dept was talking to the anyone at the mechanical engineering dept at chrysler
<rdrop-exit>
I remember you mentioned this before
<tp>
both disciplines were convinced the other guys were talking bs
<tp>
they honestly believed it
<tp>
and all it was that their disciplines were so different
<rdrop-exit>
that's why having cross-disciplanry guys on a team is so important
<tp>
so misunderstandings between C and Forth users is to be expected because both languages are so different
<tp>
rdrop-exit, agreed
<rdrop-exit>
someone who groks both gestalts
<tp>
rdrop-exit, *if you can find any*
<tp>
brb
<rdrop-exit>
probably rare nowadays
<rdrop-exit>
ok
rdrop-exit has quit [Quit: Lost terminal]
<Zarutian_HTC>
rdrop-exit: I grok both Forth and C. The former is concative programing paradigm while the latter tries to be formulatic and top down structured
<Zarutian_HTC>
tp: ^
<tp>
Zarutian_HTC, ?
<tp>
Zarutian_HTC, aha
<tp>
In my case, Im just a technician who is somewhat familiar with both in the embedded space
<tp>
I have varous types of both set up here, and have used all the different kinds that I could
gravicappa has joined #forth
_whitelogger has joined #forth
rdrop-exit has joined #forth
<DKordic>
What could possibly be formulaic about C at all? Especially compared to Forth?
<rdrop-exit>
I don't understand the question
<DKordic>
Zarutian_HTC claims C makes any sense.
<tp>
I've decided to reject any description of anything that's comprised of less than 100 words ...
<tp>
it's the 'tp hypothesis'
<rdrop-exit>
I ignore any comparisons to Forth that treat Forth as if it were merely a programming language
<rdrop-exit>
irrespective of what the ANS standard people would have you believe
<rdrop-exit>
"The rage springs not so much from a sense that Forth violates certain well-established rules and conventions as from the suspicion that Forth proves that many of these rules and conventions are meaningless" -- Jack Woehr
<rdrop-exit>
"Forth is a complete system. It is a self-contained operating system, multitasking executive, editor,
<tp>
DKordic, I'm a tech, I lack the correct programmer terminology
<DKordic>
CTAGS is W:Greenspun's_tenth_rule of C(11) in C(11) itself!!
<DKordic>
tp: Just my 2 cents :3 .
<tp>
DKordic, I wrote the XSLT transforms, and they use data 'derived from', but I do it all automatically ;-)
<tp>
DKordic, with shell scripts
<tp>
so who has a theory why Keil use #defines ?
<tp>
is it because C lacks a better way, or is it a 'better way' ?
<rdrop-exit>
it's often the simplest way, sometimes it makes more sense to use a const
<tp>
rdrop-exit, is this another level of abstraction ?
<rdrop-exit>
#defines are macro processor directives, no abstraction, just source text preprocessing
<tp>
rdrop-exit, my understanding is that the C compiler doesnt know about #defines which are 'pre-processed' before C gets the header ?
<tp>
as the code is preprocessed, it seems like a abstraction to me
<tp>
for instance, the API ? is more or less a summary of the #define
<rdrop-exit>
it's just text replacement
<rdrop-exit>
#define FOO 7
Guest59598 has joined #forth
<rdrop-exit>
x+=FOO;
<rdrop-exit>
is handed to the compiler as x+=7;
<tp>
I ask because I observe again and again that embedded C programmers have almost no understanding of bitfields or their use
<tp>
and I was coming to the conclusion that something shields them from bitfields
<rdrop-exit>
that may have more to do with the programmers you're speaking too, than any aspect of C, don't know
<tp>
yeah, it's that thinl line between programmers and hardware people
<rdrop-exit>
C programmers are often shielded from the actual bitwidth of a variable, unless they define their variables using the specific bitwidth, e.g. uint32_t
<tp>
yes, that also makes sense
<rdrop-exit>
e.g. for constants UINT32_C
<rdrop-exit>
I almost never use the run of the mill, int, long, short, etc...
<rdrop-exit>
In all my C code I have abbreviations for the specific bitwidths
<rdrop-exit>
SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); } // branchless
<rdrop-exit>
oops missed the comments, just a sec
<rdrop-exit>
SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); } // branchless
<rdrop-exit>
damn it won't copy comments for some reason
rdrop-exit has quit [Quit: Lost terminal]
rdrop-exit has joined #forth
<rdrop-exit>
trying agin
<rdrop-exit>
Binary logarithm (ceiling).
<rdrop-exit>
*** N.B. clog2(0)==0 ***
<rdrop-exit>
SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); }
<rdrop-exit>
SI is static inline
rdrop-exit has quit [Read error: Connection reset by peer]
rdrop-exit has joined #forth
dddddd has joined #forth
<veltas>
presiden: I literally was about to post this here
<veltas>
I can't help but read it and think "what a moron" and "why did you tell us this"
<veltas>
I get that he was trying to be helpful but this story makes me seethe at him, I would never ever release software personally or in a company writing raw blocks to a drive without understanding the layout and boundaries of the drive...
<veltas>
This is the kind of mistake that puts you out of business in a sane world
<veltas>
And annoying I'm 100% sure that there are people that will save this as an example of "why to avoid forth" or "why forth is bad"
<veltas>
annoyingly*
<veltas>
I literally just applied the forth block model to some code at work, because it elegantly describes caching with enough inference to be faster than some kind of dumb caching abstraction
<veltas>
Am I overwriting someone's data? No, because I know the *format* and *layout* of what I'm writing to. I can't imagine not knowing that when writing raw blocks....
mayuresh has joined #forth
mayuresh has quit [Client Quit]
jsoft has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
rdrop-exit has joined #forth
<rdrop-exit>
"Une grande responsabilite' est la suite inse'parable d'un grand pouvoir." -- Voltaire
<rdrop-exit>
veltas, I agree
TCZ has joined #forth
jsoft has quit [Ping timeout: 264 seconds]
_whitelogger has joined #forth
TCZ has quit [Quit: Leaving]
rdrop-exit has quit [Quit: Lost terminal]
jsoft has joined #forth
TCZ has joined #forth
TCZ has quit [Client Quit]
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
merkc0 has quit [Ping timeout: 264 seconds]
gravicappa has quit [Ping timeout: 265 seconds]
Zarutian_HTC has quit [Ping timeout: 265 seconds]
jsoft has quit [Ping timeout: 260 seconds]
<MrMobius>
tp, do you replace all those #defines from Keil with Forth words?
Zarutian_HTC has joined #forth
gravicappa has joined #forth
<tp>
MrMobius, I do, but they're derived from the STM32 CMSIS-SVD for each MCU type using XSLT transforms
<tp>
(my thanks tp DKordic for the correct terminology)
<tp>
tp = to
<MrMobius>
tp, how much firmware space does that take?
<tp>
MrMobius, the firmware space required varies as my system allows the generation of this data on a per peripheral basis
<MrMobius>
so it wont store words for peripherals you arent using?
<tp>
MrMobius, correct, and even then although I tend to load all the generated memory map words during development and select bitfield words by hand, I'm working on a parser that eliminates non used words
<tp>
this is for resident a resident forth, a tethered Forth doesnt have that issue as only the generated stand alone binary is mcu resident
<tp>
MrMobius, but even the tether I use for msp430 uses the same words derived from a CMSIS-SVD for MSP430 type using XSLT transforms
<tp>
lol, because the tethered host is a arm cortex-m4
<tp>
talk about cross polination!
dys has joined #forth
reepca has joined #forth
reepca has quit [Read error: Connection reset by peer]