For most programmers, it is foolish currently develop in mac

All development related issues welcome

Moderator: Moderator Team

clark_hobby
Posts: 11
Joined: Tue Sep 09, 2014 1:56 am

For most programmers, it is foolish currently develop in mac

Post by clark_hobby »

...
Last edited by clark_hobby on Sun Dec 06, 2015 5:46 pm, edited 1 time in total.
User avatar
EmuandCo
Developer
Posts: 4723
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: For most programmers, it is foolish currently develop in

Post by EmuandCo »

I don't get it why this says it is foolish to code in Mac...
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

If my post/reply offends or insults you, be sure that you know what sarcasm is...
Forever Winter
Posts: 131
Joined: Sun Oct 20, 2013 6:50 am

Re: For most programmers, it is foolish currently develop in

Post by Forever Winter »

Looks like it is actually a truncated "machine code" ...
justincase
Posts: 441
Joined: Sat Nov 15, 2008 4:13 pm

Re: For most programmers, it is foolish currently develop in

Post by justincase »

Correct, it does appear to be a truncated form of "machine code", but that still doesn't explain the bit about it being foolish (whatever you decide to interpret 'it' as). I may not have a copy of the book, but I used Amazon's 'search inside' function and it showed no instances of "foolish" in the book. :?
(too bad I can't make that confused smiley look the other way :()
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.
User avatar
Black_Fox
Posts: 1584
Joined: Fri Feb 15, 2008 9:44 pm
Location: Czechia

Re: For most programmers, it is foolish currently develop in

Post by Black_Fox »

Smells fishy.
Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: For most programmers, it is foolish currently develop in

Post by Webunny »

Black_Fox wrote:Smells fishy.
Yep, a bit, granted.

But at least the "Please erase the messages I should not have written, I did not wanted mess up the forum" indicates he's (probably) no (ordinary) spammer. ;)

I'm not really sure where he is going with all these posts neither, though.


clark_hobby; what exactly is it you want to convey? You seem to focus on machine language / binary stuff, but how is it related to ROS?
clark_hobby
Posts: 11
Joined: Tue Sep 09, 2014 1:56 am

Re: For most programmers, it is foolish currently develop in

Post by clark_hobby »

...
Last edited by clark_hobby on Sun Dec 06, 2015 5:47 pm, edited 1 time in total.
Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: For most programmers, it is foolish currently develop in

Post by Webunny »

clark_hobby wrote:
Webunny wrote:
Black_Fox wrote:Smells fishy.
Yep, a bit, granted.

But at least the "Please erase the messages I should not have written, I did not wanted mess up the forum" indicates he's (probably) no (ordinary) spammer. ;)

I'm not really sure where he is going with all these posts neither, though.
Please forgive me if messages that I posted are hindering the forum, please delete these posts, I did not want to disrupt the forum.


Webunny wrote:clark_hobby; what exactly is it you want to convey? You seem to focus on machine language / binary stuff, but how is it related to ROS?
I ask that the developers of ReactOS answer me if for most programmers, it is foolish currently develop in
machine code, hexadecimal and assembly.
I do not think they are hindering per sé, it's just that the meaning or the relevance (or both) is not too clear. I mean, ROS devs can't answer 'in general' for all programmers. I would say there are some cases where programmers do use assembly and they'll have a reason for it in those cases. But I think we already had that discussion in some thread, no? As for the devs themselves, whether they use it for ROS, has also been answered. I'm no coder, so I refrain from making definite statements, but I believe there is little reason to use binary or assembly, but whether they think it is 'foolish', I dunno. The question seems a bit strange. I mean: does it matter whether some may think it is foolish or not?
ekohl
Developer
Posts: 16
Joined: Thu Sep 29, 2005 3:00 pm

Re: For most programmers, it is foolish currently develop in

Post by ekohl »

Hi clark_hobby,

I do not think the use of any programming language is foolish. The choice is either good or bad, depending on the project and on your skills.

If you want to learn about how a CPU works, you can write a little program in assembly language, convert it into machine code and type the hex code into the
keypad of a single board computer. I did it once for the hardware lab test at the university (i8085 single board computer). It was nice to see the serial send and receive code transfer bytes from one board to another via a 3-line serial connection, and to see the bits on the digital oszilloscope. Calculating the jump offsets was fun first but it was annoying to redo the calculations in order to fix the bugs.

In my very personal opinion it does not make sense to write a progam in (hexadecimal) machine code. It is a nice one-time exercise, but you do not want to do it again.

If you have a project where code needs to be run as fast as possible, where each nanosecond counts and there is no way to do it in a high(er) level language,
assembly language is the language of choice. For all the other code you need to write, use a language that is readable and maintainable. Readable means, that other progammers can understand it. A programmer who knows C can also understand a lot of PHP, C++, C#, JAVA and to some extent PASCAL, Delphi, Algol etc. On the other hand, a programmer who knows x86 assembly language is not able to understand most of 6502, 68000, arm, ppc, sparc, alpha or z80 assembly languages without using the CPU manual. Maintainable means, that is easy to understand the code, find bugs, change the existing code or to add new code. That is where high level languages shine.

Modern compilers do a pretty good job at converting high level language code into assembly language or machine code. In most cases, modern optimizing compilers are almost as good as experienced assembly language programmers. And manual optimization of generated assembly language code is only needed in very rare cases.

Using assembly language in places where it is not absolutely neccessary is just a waste of time. And using the right high level language can save you a lot of time. After all, getting a job done in an hour is a lot more fun than having to spend a whole day to get the same job done.

Please remember, this is my very personal opinion based on my very personal experience (6502, 68000, x86, basic, pascal, c, java and some more stuff like php, tcl, xml, xsl, sql). Others may have an entirely different opionion about this topic.

Regards,
Eric
User avatar
Reactionist
Posts: 11
Joined: Thu Jan 23, 2014 5:53 am
Location: Omnipresent
Contact:

Re: For most programmers, it is foolish currently develop in

Post by Reactionist »

FYI:

The topic starter is a troll that's known to have been polluting other programming sites with irrelevant if not senseless messages similar to what you have just read at the top of this page.

His other known nicks are français, monsieur, and Jorge Monsieur.

The sooner this entity goes to ban, the better.

Re: http://board.kolibrios.org/viewtopic.php?f=32&t=2877
Mike
___________________________________________________________________________________________________________________________
(3.6GHz i5 Core Quad, 16GB RAM / 2 x nVidia GTX 650Ti SLI-bridged, 2GB VRAM; Win 7, 8.1, 10 / Ubuntu 16.04 LTS)

User avatar
EmuandCo
Developer
Posts: 4723
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: For most programmers, it is foolish currently develop in

Post by EmuandCo »

If I ban him now, I could ban ANYONE coming here. ^^ N00bs are everywhere. Let him be for now.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

If my post/reply offends or insults you, be sure that you know what sarcasm is...
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: For most programmers, it is foolish currently develop in

Post by PurpleGurl »

I concur with what the devs have already said on lower level languages.

I used to program for DOS using a mixture of Quick Basic and assembly. For some tasks, BASIC is too bulky. I mean, they do extra things you don't need and then you have to use other code to undo the extra stuff, when you can make a system call and get the data you need directly out of the CPU registers. I will give an example. In QuickBasic, there is the GetInkey$ function. That will return any characters typed as a string. Now, what if you need the ASCII value numbers instead? For a number of things I did, it made more sense to have the ASCII codes. So you might code X=ASC(INKEY$). That would bring in extra code and functions. I found it more efficient to make a DOS or BIOS call to poll the keyboard, and it would be in a CPU register as an ASCII code. And if you want to build a string on your own using that, you can.

If you create a local-only string in an assembly module to be used with QuickBasic, you would not need a string descriptor, but if you are passing it back to Quick Basic from an assembly module or directly calling Quick Basic's internal routines, you'd have to at least use a fake string descriptor. The first word (I think) was the address to the actual string, and the second word might have been the length, or maybe that is backwards. I'd have to look at some old code to know. So to call Quick Basic's own linking library (or a replacement) from assembly, you'd have to pass string functions the address of the relevant string descriptors. In assembly, you could do a number of cheats with the string functions, like if a string is at either end of another string, and you could make more than one string descriptor for different parts of the same string.

Plus an assembly module could have multiple entry points. So if it used a variable to set the function of the module, you could have multiple entry points. The main module could set a variable one way, but another module located immediately before it could set the variable another way and then do a short jump into the main module past the variable assignment there. Now if both modules have the same calling conventions, then you wouldn't have to worry about corrupting the stack by doing that. So you would not be duplicating code.

Coding in assembly helped me to figure out how to write better Quick Basic code. For instance, I was in the habit of using AND a lot in IF...THEN statements. However, when I saw what that compiled into, I realized that nested IF statements would be more effective. I was only wanting both conditions to be true, I wasn't wanting a logical comparison. Sure, that also worked, since assigning both conditions a value and then doing a logical AND would produce -1 if it were true. I used to be byte conscious and while using AND made the code look smaller, it actually caused it to compile roughly 16 bytes more for each clause. I didn't understand why until I saw the code in assembly. That involved unnecessary instructions and caused every condition to be tested each time. It makes more sense to have nested IF statements, and nested in order of likelihood to fail. If it fails, it would just be a short jump around all of the other tests (if any is false, all is false, so once you find it to be false, further tests won't help at all). That would allow it to get to subsequent code faster. That was a case in which I didn't have to code anything in assembly to get better code, just change my strategy in Quick Basic.

I learned some tricks from a book that might have been entitled "The Zen of 8086 Assembly" or something to that effect. It told about how to approach it from a position of science. You could sit down with an instruction reference list and check out things like the clock cycles consumed and so on. Then you could call the system clock every so often and see how much time elapsed to see what strategy is more efficient. Since the older CPUs used microcode and not dedicated circuitry to multiply or divide, those operations took a long time (60-80 cycles). However, bit shifting only took 3 cycles. So if you wanted to multiply or divide by a power of 2, you'd do better to shift than multiply. The book also covered alignment, and so you would add EVEN before jump targets and data blocks, and that would tell the assembler to pad out with 90h (nop, or no-op) if necessary to ensure the next address is on an even boundary. That was so the 286 CPU would be able to do the entire operation in one pass, not take 2 passes because of straddling. Yes, adding 90h would consume a cycle, but it is justified at the start of loops, especially ones with many iterations, and frequent jump targets. So if you waste a cycle before the loop, but save several hundred or more, that is worth it. You can sometimes use opcodes in nonstandard ways to save cycles. But you have to watch that since that could reduce compatibility in some cases. For instance, if you knew you had an NEC V20 or V30 CPU instead of the Intel 8088/8086, you could use a few opcodes that don't exist on Intel's chips. You could change the number base of the shift operation to where you could shift by tens rather than twos. That would save cycles, but the 8088/8086 won't run that. I even learned about self-modifying code. That practice has always been frowned upon, but it has its uses. The Quick Basic linking library might have used that in places, but if not, the PDQ replacement certainly did (I saw the source). The problem with that is cache differences between CPUs. Like I once tried self-modifying code as a way to save space, but then I found it would not run on a 486 (but it would work on a Pentium and on a 386, and presumably 286, V20, and 8088). Of course, if you had to use that, you'd want to try to clear the CPU's prefetch queue such as using a jump instruction to the very next instruction before running the code that you modified during execution. That seems wasteful, but that was to ensure it worked on more machines, since the old CPUs cleared their queues on jumps and were not intelligent enough to keep what was still valid in the queue. So you'd want to make sure the new code is in the buffer, not the old code. Like I said, it is best to avoid self-modifying code, since it could introduce incompatibility, and might even get flagged by a malware scanner (if it cannot figure out that is a desired change and initiated by the running program itself and not a virus).

QuickBasic did include functions to let you call interrupts, but that added a lot of unnecessary code. I mean, why do you need an interrupt function when the CPU can do that natively? Some of that was hand-holding and debugging, but if you knew what you were doing, you could do it directly in assembly without trouble. I ended up writing mouse routines in assembly. Sure, you could call the interrupt function, but then you ran into a convention problem, since some of the interrupts take unsigned numbers, and QuickBasic only uses signed numbers. So if you wanted to pass 65535, you'd have to pass -1. That meant using a long number to make the conversion and then doing the subtraction if the number is at the max for signed integers. 16-bit CPUs didn't natively work with 32-bit numbers, so the long number library had to be brought in by the compiler (if you wanted to use a stub to use CPU instructions only for this, you'd have to have at least a 386 and should add some code to test for that and exit if not compatible). Rather than doing any of that, you could directly pass what you need to the interrupts in assembly. So no stuffing fake registers to pass to the real ones, no bulky prologue/epilogue, no signed v. unsigned issues, no need to call in 32-bit emulation code, etc. So it was more natural to write mouse handlers in assembly.

Anyway, I liked the ease and power of writing in Quick Basic, all while using the performance and flexibility of assembly in places where that would help.
Last edited by PurpleGurl on Mon Apr 17, 2017 10:36 pm, edited 2 times in total.
User avatar
dizt3mp3r
Posts: 1873
Joined: Mon Jun 14, 2010 5:54 pm

Re: For most programmers, it is foolish currently develop in

Post by dizt3mp3r »

Whether or not the OP is a troll, he started a thread that caused some good responses.

Quickbasic 4.5 is a lovely little language and I still find myself pulled back to it from time to time. Quickbasic 64 has a QB 4.5-cloned IDE and emits C++ code. It is what all languages should be at the very least - easy to use, solid, has a defined standard, has a future and is multi-platform. I abandoned QB4.5 years ago due to the memory limitations but QB64 has dispensed with these. I keep looking for a reason to pick it up again and use it.

Has anyone tested QB64 on ReactOS?
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
gamax92
Posts: 35
Joined: Sun May 05, 2013 5:40 pm

Re: For most programmers, it is foolish currently develop in

Post by gamax92 »

Ahh ... QuickBasic, my go to for quickly testing some stuff.
I like QB64 for its extensions but it does suck it does not have a interpreter mode, only compiler.
It cuts down on productivity speed when what you're working spends more time compiling than it does running.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: For most programmers, it is foolish currently develop in

Post by PurpleGurl »

dizt3mp3r wrote:Whether or not the OP is a troll, he started a thread that caused some good responses.

Quickbasic 4.5 is a lovely little language and I still find myself pulled back to it from time to time. Quickbasic 64 has a QB 4.5-cloned IDE and emits C++ code. It is what all languages should be at the very least - easy to use, solid, has a defined standard, has a future and is multi-platform. I abandoned QB4.5 years ago due to the memory limitations but QB64 has dispensed with these. I keep looking for a reason to pick it up again and use it.

Has anyone tested QB64 on ReactOS?
I never heard of QB64. I used QB45 the most and never really went to 7.x or whatever. Yes, QB 4.5 only produced medium model code. So that meant that each memory segment could not exceed 64k. At least it didn't use tiny model which would mean 64k for everything (data, code, and an undefined stack), though there was a Tiny Basic or something that was a compiler directly into .com files. I used that one on occasion mainly to create configuration programs for larger programs. You could use that to create a settings file to be read by a larger program. It was quick and dirty.

What got me into assembly with Basic was PDQ. That was a custom, 3rd party link library to use with QB (both the medium model version 4.x and the large model version 7.x). It was expensive, but included the source code. I read through that and a couple of 8086 manuals and realized how easy it was to write assembly modules to use with QB. It allowed me flexibility and performance. For instance, I stopped using DATA statements, but instead put the data in assembly and created functions to tell QB code where to find it. That used less memory since with DATA, you had to read the data into variables before using it. If you knew its address, you could simply use PEEK to read it. If you needed to do more, you could call QB's internal functions from assembly, like B$SASS (string assign), or you could treat your block of memory as an array and manage your custom array in assembly and give QB a clean package to work with.

Then someone gave me a copy of Sourcer. That was a disassembler. I liked how it worked with .obj files, so for things written in C or assembly, you could get clean, representative code. (But disassembling QB object code or trying to assemble a QB compiler listing was hopeless). That came in handy too, since if someone had written functions in or for C, I could reassemble it to where it didn't use illegal keywords as symbols, and instead passed variables according to the BASIC/Pascal conventions. That made it easier to use such modules in QB. Oh, there were workarounds, such as the Alias keyword and the C_decl clause to tell it that the functions used the stack the opposite of the expected way. But it would be easier if the name and prologue/epilogue were already compatible. In some cases, when I converted the source code from C convention to BASIC convention, I found things that could be optimized, and I removed the 90h and replaced with EVEN in case they assembled a little differently and ended up a few bytes off or so, so things would remain even.

I also learned about undeclared memory in that. I wondered why programs often used more memory than their size, and if you disassembled and tried to reassemble, the program's size would balloon. That was because they used uninitialized memory. The memory was outside the scope of the program. If it was initialized and fully declared, the program size would jump as the entire memory area used would be loaded with the program. So fixed variables would be compiled as part of the code, but arrays often would not be. So there is no need to overwrite memory where you don't care about what is there, just let the OS know you are using it (and that is the compiler's job).
Post Reply

Who is online

Users browsing this forum: No registered users and 12 guests