Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

converting minised to TP or asm (Announce)

posted by Rugxulo(R) Homepage, Usono, 20.07.2019, 18:00

> > > > I want to port minised to TP. Should be easy (famous last words)!
> > >
> > > Why TP, when it already exists written in another language?
> >
> > I think it would be an interesting comparison. But I admit there is no
> > super-obvious advantage. Still, who knows if it would be easier to speed
> > up or fix bugs.
> I'd also be interested in converting it to assembly. I always had the gut
> feeling that most C programs were horribly bloated, roughly 10x more than
> they should be. So I blindly guess that an asm-written minised could
> optimally be 4 or 8 kb (uncompressed). Of course, TP has a smartlinker,
> so it matters less there if written in Pascal. I do prefer TP over asm
> these days.

Classic J&W Pascal had limited string ("packed array [1..n] of char") support. I think UCSD Pascal was the inspiration for TP's "string" type. It feels almost like BASIC (no annoying bugs like in C where arrays decay into pointers/addresses). In fact, QBASIC or REXX would also be good tools for this kind of problem. (I'd already rewritten my A86 sed script into BAS, TP, C, and AWK, for comparison.)

So I finally rewrote my latest simplified FASM sed script into TP. I have a feeling that Prof. Wirth or Prof. Kernighan would call it too ad hoc. It should be simpler, more modular, more generalized! But at least it works and doesn't depend upon sed. With TP 5.5, it's only 5 kb (or 3 kb UPX'd). Not too shabby! Still, what little you save in size also means reduced functionality. Sed is better than an ad hoc, one-time, "black box" (opaque) solution.

Sets can be useful: "ch in ['a'..'z','A'..'Z','0'..'9']" = "[a-zA-Z0-9]". Although it's a size penalty to use that in TP when you don't truly need it. A few simple comparisons (like C's isalnum() function) here would have sufficed instead. So actually it was 5.5 kb until I avoided sets, then it's only 5 kb. Almost pointless to worry about such small savings, but I truly didn't need all the extra set functionality, so it should be avoided (for this one compiler).

Also, Modula-2 and Oberon are much more limited with their SETs/BITSETs. Basically, SET there is just a (byte-ending neutral??) abstraction for bitwise operations only for word-sized data (for 32-bit INTEGER, e.g. MIN(SET)=0 and MAX(SET)=31). I think J&W Pascal tried to support "set of char" (basically "array [0..255] of boolean"), but the ISO standard didn't demand that, sadly. This was one of BWK's complaints, that sets were too weak, but obviously it can be worked around or avoided. It wasn't necessarily meant to handle literally every scenario, just some limited uses.

I think C was loosely inspired by SNOBOL with such functions like strcspn() ("find first char in s1 that matches any char in set"), etc. (Icon is also an interesting successor to SNOBOL, but I'm not truly familiar with either one.)

I also wonder about Forth. I never truly learned it, plus I think it lacks some advantages of modular Wirth languages. But it's still good and has its own advantages (in small size, simplicity, portability, dynamicity = run-time vs. compile-time, etc). You know, interpreters don't have to be huge (sed isn't) for limited functionality. It just takes some TLC, some elbow grease, to finesse and whittle down everything to a reasonable subset.

Whatever, just something I'm thinking about. :lookaround:


Complete thread:

Back to the forum
Board view  Mix view
15889 Postings in 1469 Threads, 269 registered users, 91 users online (1 registered, 90 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum